Loomplane / Platform

See every change before it happens.

Discovery tells you what your repositories contain. The manifest says what to deploy. A plan shows every action it would take. You approve that exact plan, and Loomplane carries it out and keeps it true.

Discovery

It reads your monorepo so you don't have to describe it.

Point Loomplane at a GitHub URL. It walks the checkout and finds the services it would build, the packages they share and the databases they need. Every result carries source evidence you can open.

  • Go, Rust, Node, Python and JVM (Maven and Gradle) projects, Dockerfiles and Compose files
  • Forge layouts, app roles and scoped backend configuration
  • Examples, fixtures, test data and scripts stay out of the default graph
  • Private repositories through a GitHub App, re-analyzed on every push
  • An application split across several repositories, analyzed as one project
Analysis · acme/monocommit 3f9e1a · 41s
apigo:services/api · cmd main.go:12
http-service
workerservices/worker/cmd/worker · main.go:9
worker
webapps/web · package.json:5 next
web-app
dbpostgres · services/api/go.mod:14 pgx
resource
cacheredis · compose.yaml:22
resource
examples/polyglotexcluded · examples directory
skipped
loomplane.yaml

A versioned manifest, drafted for you.

Loomplane drafts loomplane.yaml from the analysis. Edit it in the dashboard, in your editor, or with loomctl manifest save. Every save is a new revision, and each plan names the revision it came from.

  • Services, resources, gateways and per-environment overrides
  • A JSON schema for completion and checks in your editor
  • Placement controls that edit the YAML and keep your comments
  • Unknown fields and unsupported versions are rejected, with the line
loomplane.yamlYAML
services:  api:    source: go:services/api    kind: http-service    port: 8080    public: true    needs: [db, cache]    scale: { min: 1, max: 5 }    environments:      staging:        scale: { min: 0, max: 2 }      production:        region: europe-west1ignore:  resources: [kafka]   # found, not deployed
revision 14schema loomplane.json
Plans and approvals

Approval names the revision you reviewed.

A plan lists every action a deployment would take, in order, with the problems that block it and the things worth knowing. An Admin approves that exact plan. If the manifest or a cloud changed in the meantime, the plan comes back stale and nothing runs.

  • Plans wait up to a week for a decision by default
  • Scope a plan to some repositories and leave the rest as deployed
  • Deletions are shown like any other change, so nothing disappears quietly
Plan 9b21e0 · stagingstale
update apiscale min 0, max 2
change
remove searchservice turned off in revision 15
delete
Blocked: missing permissionrun.services.update on acme-staging
fix
Revision changedmade from 14, manifest is now 15
re-plan
Live deployments

Watch each step build, deploy and answer.

Approval starts a durable workflow. You follow every step live in the dashboard, and the environment shows what runs where afterwards. If a step fails, the retry starts from that step instead of the beginning.

  • Events and build output are saved before they're shown, so a restart loses nothing
  • Live updates over WebSocket, falling back to SSE and then plain refresh
  • A Live badge only when the status heartbeat is recent
  • Email and signed webhooks when a deployment finishes
deploy api · cloud-runlive
14:02:11 build    cloud-build  step 1/4 fetch source14:02:19 build    cloud-build  step 2/4 go build ./services/api14:02:58 build    cloud-build  image pushed sha256:8c1f…14:03:04 deploy   cloud-run    revision api-00014 created14:03:22 deploy   cloud-run    waiting for ready14:03:31 check    https://api-xyz.run.app/healthz 20014:03:31 traffic  100% to api-0001414:03:32 done     api is live · 1m 21s
Drift

What runs is what you deployed.

A scheduled check compares every deployed service and resource with what's actually live. When someone scales a service by hand or edits it in a console, the difference shows up, and the next plan puts it back.

  • Every 30 minutes by default, set with LOOMPLANE_DRIFT_INTERVAL
  • Drift shows on the environment and through loomctl status
  • Corrections go through the same review as any other change
acme / mono / productiondrift check
productionchecked 14:30 UTC
dbcloud-sql · postgres 17
matches
apimax instances 5 to 12 in the console
drifted
workerecs-fargate
matches
webvercel · acme.dev
matches
4 checked · 1 drifted · next check 15:00
Gateways and networking

One public address in front of services on any cloud.

Gateways route paths to services, built on Bastion and run on your infrastructure. Services find each other through variables. ECS services reach each other privately, and private Cloud Run services only take calls from the project's own.

  • Path routing with optional prefix stripping
  • Public addresses only for what serves HTTP, unless you say otherwise
  • Domains you manage alongside the routes that use them
Gateway edgeacme.dev
/apito api · Cloud Run · prefix stripped
us-central1
/to web · Vercel
edge
workerprivate · no route
ECS
Get started

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:latestServer
$brew install xraph/tap/loomctlCLI
Read the install guide