Each service on the cloud that suits it.
Connect the accounts you already have. A Google Cloud service account key, a Vercel token, an AWS access key, a Render API key, a DigitalOcean token, an Azure service principal. Each is checked with its cloud before it's kept, and Loomplane tells you which permissions are missing.
Where things run, and where they're built.
| Provider | Services | Databases, caches, buckets | Builds on |
|---|---|---|---|
| Google Cloud | Cloud Run | Cloud SQL (PostgreSQL, MySQL), Memorystore, Cloud Storage | Cloud Build |
| AWS | ECS on Fargate | RDS (PostgreSQL, MySQL), ElastiCache, S3 | CodeBuild |
| Vercel | Web apps, static sites | None | Vercel |
| Render | Web services, workers | Render Postgres, Key Value | Render |
| DigitalOcean | App Platform | Managed PostgreSQL, MySQL, Valkey | App Platform |
| Azure | Container Apps | Azure Database for PostgreSQL and MySQL, Azure Managed Redis | ACR Tasks |
| Your servers | SSH with Docker, Kubernetes namespaces | The service catalog's engines | Your registry |
| Anything else | A provider plugin | A provider plugin | Your choice |
Pick a target by name, not by account ID.
Group accounts into a Cloud, give each target a name like frontend, and assign the Cloud to an environment. Your manifest refers to frontend, and production and staging each resolve it to their own account.
- One connection per cloud per environment, shared by its services
- With one ready account, Loomplane picks it for you
- Account choices are saved on the server and used by the dashboard, CLI and API
services: web: source: node:apps/web cloud_target: frontend$ loomctl clouds create mono --name Production$ loomctl cloud-targets create mono cloud_7d2 \ --name frontend --provider vercel --connection conn_41a$ loomctl clouds assign mono env_prod --cloud cloud_7d2 \ --revision 0 --wait --timeout 10m assigned · web resolves to vercel/acme-prod
Bring what already runs. Move it when you're ready.
Adopt an existing service by describing where it runs today. When the placement matches what already serves, the plan records it without redeploying anything. Later, replace the account or switch providers, and the plan shows exactly what moves.
- Adoption that changes nothing when nothing needs to change
- Follow and recover a sync if a provider call goes missing
- Finish external routing or revert it, step by step
- A Cloud switch never moves database contents behind your back
Your own machines are a target too.
Connect an SSH server with Docker or a Kubernetes namespace, group servers into pools, and share them across projects. When you need a target Loomplane doesn't ship, write a provider plugin in Go, run it, and point Loomplane at it.
- Storage inventory for every Docker volume and Kubernetes claim
- Pause a target to stop new work landing on it
- A provider protocol with its own test suite
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