One organization per request
Your session or API key picks the organization, and nothing in a request can change it. Another organization's projects aren't found, the same answer as something that doesn't exist.
Loomplane holds the keys to your infrastructure, so it's strict about who acts, in which organization, and where every secret lives. Here's how.
Your session or API key picks the organization, and nothing in a request can change it. Another organization's projects aren't found, the same answer as something that doesn't exist.
Warden roles decide what each person can do. An API key acts as the person who made it, with their role, and loses it when they do.
Credentials and secrets are encrypted with keys derived from your secret key, kept in Vault, and written to each cloud's own secret store.
Chronicle keeps an audit trail of every change in the organization: who, what and when.
Repository analysis is static, in a separate worker. A repository's scripts don't execute on Loomplane.
Owners and admins manage signed webhooks. Deployment mail checks the recipient's current membership and project access before it's sent.
| Role | Can |
|---|---|
| Viewer | Read everything except secret values, and change nothing |
| Developer | Create projects, analyze, edit manifests and variables, and plan |
| Admin | Approve plans, retry deployments, manage connections, secrets and members |
| Owner | Everything, including the organization itself |
In production, Loomplane won't start without a real secret key and an HTTPS public address. Endpoint checks from your targets never connect to Loomplane's own host, database or API, and you can deny more ranges on top.
$ LOOMPLANE_ENVIRONMENT=production loomplanerefusing to start: - LOOMPLANE_SECRET_KEY is the development key - LOOMPLANE_PUBLIC_URL must be https# 32 random bytes, base64$ openssl rand -base64 32
Open source and self-hosted. Your applications don't need Forge, or Go.
docker pull ghcr.io/xraph/loomplane:latestServerbrew install xraph/tap/loomctlCLI