The platform
Sprintsail is managed Kubernetes, operated by Orion. You push source code; the platform builds it, runs it, keeps it running, and gives you logs, per-instance metrics, and scaling controls over it.
You do not create clusters, write manifests, or patch nodes. Capacity, upgrades, and the runtime underneath your applications are ours to operate. What you work with is a small set of objects — orgs, spaces, apps, and services — and two ways to drive them.
One API, two front doors
The console and the CLI are both clients of the same API. There is no console-side database keeping its own version of the truth, which is why the two never disagree:
- Create a space in the console and the CLI sees it immediately. Delete it in either place and it is gone in both.
- App status in the console is the same status the CLI reports — neither view keeps its own separate record of what is running.
- Logs and metrics are the same stream and the same numbers in both places, not a summarised or delayed copy.
Use whichever suits the moment. Nothing is console-only, and nothing is CLI-only.
How permissions work
Every action runs as you.
When you do something in the console, the console does not act with elevated platform credentials on your behalf. It forwards your identity, and the platform checks your org and space roles for that specific request. The console is a client of the same API your CLI talks to, with the same permissions you have.
The practical consequence: the console can never do more than you are allowed to do yourself. Permissions are enforced by the platform on every request, rather than by the user interface choosing which buttons to show you.
Roles are granted per org and per space, so someone can have full control of staging
and read-only access to prod in the same org.
Sprintsail and Drydock
Sprintsail is the managed offering — you get an account, you push apps, and Orion operates everything underneath.
Drydock is the same platform shipped into a customer's own environment: single tenant, deployed inside their existing authorization boundary rather than seeking one of its own, and designed to meet NIST standards. It exists for teams whose compliance posture will not allow a shared managed service.
The two are the same platform with a different operator and a different boundary, which means moving from one to the other is a deployment question rather than a rewrite. The objects you work with, the commands you run, and the way your application reads its configuration do not change.
Related
- Orgs, spaces, and apps — the objects you work with
- Services — the managed service marketplace
- Drydock — the same platform, in your own boundary