Product
You wrote the app.
We do the boring 90%
Builds, TLS, containers, restarts, the history of who broke what. Everything between a git push and a served request — here is each piece of it.
Build
Source in, container out
You should not have to describe your project to a build system that can read it. Most stacks are detected with zero configuration. Keep a Dockerfile and we use that instead. Static output skips the runtime entirely.
- Automatic detection of your stack
- Your Dockerfile, if you prefer it
- Static output served directly
-> detected: package.json, no Dockerfile-> provider: auto-detected (node 22)-> npm ci --omit=dev-> npm run buildimage built in 41sRun
A URL that just works
Every app gets a working address the moment it starts. Attach your own hostname and the certificate is requested, installed and renewed — once, then never your problem again. Nobody should be paged because a certificate expired on a Sunday.
- Let's Encrypt certificates, renewed automatically
- As many custom domains per app as you need
- Choose the port your process listens on
- Stop, start, or redeploy on demand
Attach a domain
Hostname
Certificate
https://app.acme.com
port 3000 · letsencrypt · added just now
Data
A database, without a second vendor
The usual answer is an account somewhere else, a second bill, and a connection over the public internet. Here a database is just another thing in your project: it comes up beside your app, only your app can reach it, and attaching it writes the connection string in for you.
- PostgreSQL, MySQL, MariaDB, MongoDB and Redis
- Reachable only from inside your own project
- Connection string written into an app as a secret
- Scheduled backups into a bucket you own
PostgreSQL
:5432 · backups available
Name
Plan
DATABASE_URL added to web
written in as a secret · app redeploying
Operate
When it breaks, the answer is on screen
A failed deploy should tell you why. Watch a build as it runs, read back any previous one, and see who triggered it. No support ticket, and no exit code you have to go and look up.
- Live build output while a deploy runs
- Container state, health checks and restart count
- Plain-language reason a container stopped
- Full history with status, duration and attribution
v2.4.0 done 18s Ada Lovelacev2.3.9 done 22s CI (API key)v2.3.8 error 7s Ada Lovelace build failed: missing DATABASE_URLPeople and machines
Your team, and your automation
Access that matches responsibility — for the humans, and for the scripts.
Roles
Viewer, developer, admin, owner — each one a superset of the last.
API keys
Scoped to a team and a role, hashed at rest, dead the moment you revoke one.
Secret variables
Write-only once saved. Replace them freely; nothing reads them back out.
Audit trail
Who changed what, on the record, for your organization.
API
Anything you can click, you can script
The dashboard is just one client of a documented REST API — creating apps, updating environments, triggering deploys, reading logs. It gets no endpoints you do not.
Asked first
The questions we get before the signup
Including the two answers that are not in our favour.
Do I need a Dockerfile?
No. The build detects your stack itself and works out how to build it, which covers most stacks with nothing to configure. Already keep a Dockerfile and would rather use it? Choose the dockerfile build type and we will.
Do you back up managed databases?
Yes, into an S3-compatible bucket you own — connect one once and schedule each database every six hours, daily or weekly. Your recovery copy stays in your account rather than ours. Two limits we would rather state than have you discover: Redis cannot be backed up, and restoring is manual — a backup is a dump file, and putting it back is something you do.
Can I see my container's runtime logs?
Not yet, and we would rather say so plainly. You get the full build and deploy output for every deployment, live while it runs and readable afterwards, plus the container's own state — whether it is up, whether its health checks pass, how many times it has restarted, and why it stopped. What you cannot currently do here is tail the process's own stdout once it is serving traffic. Ship your application logs somewhere that keeps them, as you would anywhere else.
Do you show CPU and memory usage?
Not per app, and we will not put a gauge there until we can fill it honestly — per-container CPU and memory are not sampled reliably enough for us to draw them. You do get the thing that usually matters more when something is wrong: the restart count, and the exit reason. A container killed for exceeding its memory limit says exactly that, rather than leaving you to look up what exit code 137 means.
What stops a secret leaking back out?
Marking a variable secret makes it write-only. Your application receives it; the dashboard and the API return null for it forever after. Replace one whenever you like, and editing your other variables leaves it untouched. There is no read path to abuse — not for you, and not for us.
Can I do all of this without the dashboard?
Yes. The dashboard is one client of a documented REST API — creating apps, updating environments, triggering deploys and reading logs are all endpoints. Issue a key with the role that job needs and nothing more.
Who on my team can deploy?
Whoever you decide. Viewers read, developers deploy and change configuration, admins manage members and keys, owners own the organization. Roles are enforced by the API on every request, not merely hidden in the interface.
What happens if we outgrow you?
Your application is a container built from your repository, so it runs anywhere else that takes containers. No proprietary manifest to unpick, nothing to rewrite. We would rather earn the next top-up than make leaving expensive.
Ship something today
Connect a repository and watch it build. From $8 a month, with nothing to cancel.