/solutions/saas

From repository to production, with staging and a way back.

Connect the repositories your product is made of, give each environment its settings once, and let a push deploy exactly the commit that was pushed — health-checked, reviewed, and one click from the version before.

Request early access Talk to us

Deploy on push
Staging and production
Rollback to any deploy

8c1e2f4feat: bulk contact importpushed to main

acme/crm main

api/Dockerfile
admin/Dockerfile
worker/Dockerfile
CLAUDE.md
.claude/skills/

@crm/apicrm-api-stg8c1e2f4
@crm/admincrm-admin-stg4f2a1c9
@crm/workercrm-worker-stg4f2a1c9

/the-path

The path a product takes. Step by step.

The same parts every team uses, in the order you meet them. Each step links to the page that explains it.

01
Connect your repositories
Install the GitHub App on the repositories your product is made of — an API, an admin panel, an app — and make one workspace of them. Every Dockerfile becomes a project.
Workspaces
02
Two servers, two environments
A server for staging and one for production, in the location you choose. Each stack says its environment, and deploying to production is its own permission.
Servers
03
Settings once per environment
Variables and secrets for production, staging and development, given at every deploy to the containers built from the workspace — the container’s own value wins.
Secrets
04
A database with backups
PostgreSQL, MySQL or any of the others — its password a secret, backups on a plan into your own bucket, a restore that takes a copy first.
Databases
05
Deploy every Dockerfile, then on push
The Deploy tab puts every project on a container at once, reviewed first. From then on a push deploys exactly the pushed commit, and a failed health check leaves the old one serving.
Deployments
06
Files in a bucket
Uploads, exports and backups in buckets with links that expire and S3 keys for your code. Downloads cost nothing.
Storage
07
Your domain, with HTTPS
A router in front of your services with certificates that renew themselves — or publish a port, or put Nginx or Caddy with Certbot on the server.
Deployments

/what-changes

What changes for the team shipping it.

Staging that behaves like production.

Both run from the same workspace, the same images and the same review — only the environment’s settings differ. A Developer can deploy to staging and ask for production; an Operator can run production. Every deploy says who did it and which commit it ran.

The commit a deploy ran is written on it — what runs and what was pushed are the same thing.
Deploying to production is a separate permission from deploying to staging.
A failed deploy or a crash tells the people who can fix it.

Deploy #148 of @crm-apiLive

crm-api…:2026.09.24-3b7d0a1removed

crm-api…:2026.09.25-8c1e2f4serving

Pull crm-api:2026.09.25-8c1e2f414 s
Start crm-api.next beside the running one2 s
Health check — GET /healthpassed in 6 s
crm-api.next takes the name · the old one goesno gap

Strategy: start beside, then switch — nothing here keeps data or holds a port.

Know what it costs, by the day.

Servers and storage are charged for the hours they exist and what they hold — never more than the monthly price. Usage shows the month so far from the very lines the invoice will carry, so there is nothing to reconcile at the end of the month.

No platform fee, no price per seat — invite the whole team.
A spending alert at the budget you set.
Downloads from buckets are free.

September so far

$128.42

Sep 25 · $5.56

Example

Add-ons
Servers
Object storage
Everything else

/trust

Nothing irreversible without you.

Safety here is a set of mechanisms you can inspect, not a badge: what the platform will not do on its own, and what it writes down when it does.

How we keep it safe

An isolated cloud per organization
Servers, networks, databases, buckets and secrets belong to one organization. Nothing is shared with anyone else.
Destructive means typed back
A tool that changes data asks first; one that destroys it asks for its name typed back. Every call lands in a ledger.
Secrets never on a command line
Encrypted and versioned, handed to a container only at deploy time — over stdin, never in a command or a log line.
See it before it runs
Every create shows the exact Docker commands it will run, with secrets by name, before anything is made.
Deploys that can’t take you down
The new container must pass its health check before the old one goes. If it fails, the old one is still serving.
Sign-in you control
Passkeys, two-factor, single sign-on with OIDC or SAML 2.0, verified email domains — and you can require them.

/start

Ship it this week.

Request early access, connect your repositories — and pay for the servers it runs on, by the hour.

Request early access Talk to us

From repository to production, with staging and a way back.

Connect your repositories

Two servers, two environments

Settings once per environment

A database with backups

Deploy every Dockerfile, then on push

Files in a bucket

Your domain, with HTTPS

Staging that behaves like production.

Know what it costs, by the day.

An isolated cloud per organization

Destructive means typed back

Secrets never on a command line

See it before it runs

Deploys that can’t take you down

Sign-in you control

Ship it this week.