Your infrastructure, woven together.
Give Loomplane your monorepo, or an application split across several repositories. It reads the code (never runs it), finds the services and the databases they need, drafts a loomplane.yaml and shows you the exact plan. Approve it, and a Next.js app goes to Vercel, a Go API to Cloud Run, a worker to ECS on Fargate and Postgres to Cloud SQL, wired together.
Good morning, Ada
One plan is waiting for your approval.
mono to production
Revision 14 · 7 actions · nothing blocking. Planned by Sam 4m ago.
billing
Staging 71eae66 Finished yesterday by you
These show up once Loomplane reads billing and metrics from your cloud accounts.
- Cloud spend
- Not connected
- p95 latency
- Not connected
- Traffic
- Not connected
- You deployed billing to stagingyesterday
- A deploy of game-framework to preview failedyesterday
- Ada approved the plan for billing to staging2d ago
- The plan for mono to staging was superseded2d ago
- Google CloudCloud Run · acme-prod3 services
- VercelVercel · Acme1 service
From repository to running services, one reviewed plan at a time.
Every deployment goes through the same six steps. Nothing is provisioned until someone with the Admin role approves the exact plan you reviewed.
# The same flow from a terminal or CI$ loomctl login --url https://loom.acme.dev --key -$ loomctl analyze mono found 3 services, 2 resources, 1 shared package$ loomctl manifest save mono -f loomplane.yaml saved revision 14$ loomctl plan mono --env production plan 7f3a2c · 7 actions · 0 blocking + provision db cloud-sql postgres 17 + provision cache memorystore redis + build api cloud-build + deploy api cloud-run us-central1 + deploy worker ecs-fargate + deploy web vercel + route edge /api, /$ loomctl approve 7f3a2c approved · deploying revision 14
One platform for the whole path to production.
Loomplane is one Go process and a worker on one PostgreSQL database. Here is what it does once it's running.
Discovery, manifests and plans
Static analysis of your repositories, a versioned loomplane.yaml, and plans that list every action before anything moves.
Six clouds and your own hardware
Vercel, Cloud Run, ECS, Render, App Platform and Container Apps, plus SSH servers and Kubernetes. Pick targets by tag and move between them.
See every target ↗ServicesDatabases with tested recovery
PostgreSQL, MySQL, MariaDB, Redis and Valkey in one click, plus the Octopus gateway and the Fabriq data fabric, with scheduled backups and restores you can test on an isolated copy.
Browse the catalog ↗CLI and agentsloomctl and an MCP server
Everything the dashboard does, from a terminal or CI. Give an agent tools to analyze and plan, and approve only if you allow it.
Read the CLI tour ↗SecurityRoles, secrets and an audit trail
Organization isolation on every request, Warden roles on every action, and secrets that live in Vault and each cloud's own store.
How it's protected ↗Self-hostRun it on a laptop or in production
Docker Compose for local work, a production guide with HTTPS and backups, live state over WebSocket, and Prometheus metrics.
Install Loomplane ↗Set a value once. Override it exactly where it differs.
Variables come in layers: organization, project, service, and each environment. Secrets go to Vault first and then to Secret Manager, AWS Secrets Manager or Key Vault. After you save one, nobody sees it again, including you.
- Services find each other through variables Loomplane writes for you
- Generated database passwords never leave Vault and the target cloud
- Viewers read everything except secret values
What people ask first.
Do my applications need Forge or Go?
No. Loomplane itself is built on Go and the Forge ecosystem, but it deploys Go, Rust, TypeScript, JavaScript, Python and JVM applications. It reads your code to understand it and builds each service on its cloud's own builder.
Does Loomplane run my code during analysis?
Never. Analysis is static. It reads package manifests, Dockerfiles, Compose files and source layout, and every service it finds links to the line that gave it away. Examples, fixtures, test data and scripts are left out of the default graph.
Where do my workloads run?
In your own cloud accounts. Loomplane holds credentials for the clouds you connect, plans the changes and drives each provider's API. Builds run on Cloud Build, CodeBuild, Vercel, Render, App Platform and ACR Tasks, in your accounts.
What happens if someone changes something in the console?
A drift check runs every 30 minutes by default. It compares what's deployed with what's live, and the next plan puts it back. You review that plan like any other before it runs.
Can I deploy to my own servers?
Yes. Connect an SSH server with Docker or a Kubernetes namespace. For anything else, write a provider plugin and point Loomplane at it without changing Loomplane itself.
Can an AI agent deploy for me?
loomctl mcp gives an agent tools to analyze, draft manifests, plan and follow deployments. Approving a plan or retrying a deployment needs --allow-deploy, so it only happens if you let it.
Deploy your monorepo to your own clouds this afternoon.
Open source and self-hosted. Your applications don't need Forge, or Go.
docker pull ghcr.io/xraph/loomplane:latestServerbrew install xraph/tap/loomctlCLI