MeerkatTake the app you
built this weekend
straight to production.
Meerkat takes a git repository, like a GitHub repo, and gives it a container build, a reviewed release pipeline, gated secrets, scanned and hardened images, and continuous watching. Nothing to stand up. Nothing to babysit. Nothing locked in.
- Your code stays in your own repo
- Secrets never touch the repo
- One command from repo to release
$ blankcut promote --repo github.com/northwind/api✓ scaffolding Dockerfile, CI, key declaration✓ repo scan no risky build patterns✓ image build api:2.14.2@sha256:9f2c1a✓ image scan no critical CVEs✓ secrets 6 keys matched, none in the repo✓ release one-file deploy change opened→ deploy reviewer checking the changenorthwind-api · digest-pinned rollout once it passes
The gap
Writing the app stopped being the hard part.
Claude Code can take a feature from idea to working code in an afternoon. Then it sits on a branch while somebody figures out Dockerfiles, a registry, secrets management, ingress, TLS, probes, autoscaling, alerting and who gets paged at 3am. That list is the whole job now, and it is the job we do.
Without a platform
- Weeks of infra work before the first user sees it
- Secrets living in a .env on one laptop
- Deploys nobody can explain or reverse
- "It works on my machine" as a release process
- An agent that invents a new way to deploy every session
- A cloud bill that arrives four times larger than the app
With Meerkat
- One command from repo to a reviewed production release
- Encrypted store and keys allowlisted
- Every deploy is a one-file diff, reviewed before it merges
- Repo and image both scanned before anything runs
- A CLAUDE.md that holds your agent to the architecture
- Resources sized for the app, so the bill is the app
How it works
Four steps, then it runs itself.
You install one app on one repository. Everything after that happens as pull requests in your own repo, which means you can read, review and revert all of it.
Connect a repository
Install the Blank Cut App on a repo you already have, or let us create a private one in your account, seeded with a runnable Next.js or Vite starter.
Merge the scaffolding PR
We open a pull request adding what's missing: a hardened multi-stage Dockerfile, the build workflow, a deploy manifest, and a declaration of the keys your app may read.
Promote the release
Each promotion becomes one change to the deployment config. The scope guard and our deploy reviewer check it, and then the scanned image rolls out with probes, right-sized resources and a rollback path.
Watch it live
App health, pod restarts, log tail, alerts and spend, all in one place and scoped to your apps.
For Claude Code users
Your agent writes the code.
We hold the architecture.
Every repo we scaffold ships with a CLAUDE.md describing the platform's conventions: where config lives, how secrets are declared, what the health endpoint must return, how a release is cut. Point Claude Code at the folder and it builds inside those rails instead of inventing its own deployment story every session.
Conventions written down, not tribal
The same file your agent reads is the one your next teammate reads.
Your agent ships with the same CLI you do
It runs blankcut, not a cloud API, so its work lands on the reviewed path.
Agent-authored changes still get reviewed
A PR is a PR, whoever typed it.
Secrets stay out of the context window
Values live in the platform store; the repo only names the keys.
# northwind-api## DeploymentThis app runs as a container on the Blank Cutplatform. Do not add Helm charts, raw k8smanifests, or a second CI system.## ConfigEvery key the app reads MUST be declared in.env.example. That file is the allowlist:an undeclared key is unavailable at runtime.## HealthGET /health returns 200 + {"status":"ok"}once dependencies are reachable.## Releasingblankcut promote --app northwind-apiOpens a reviewed deploy change.
Security, not security theatre
One stolen key should open one door.
Any platform that runs your code holds credentials for it, so the useful question isn't whether someone will try. It's how far one stolen credential gets them. On Meerkat, almost every credential is scoped to a single app, expires on its own, or is stored only as a hash.
Where every credential lives
- Your repository
Key names, never values. .env.example declares what the app may read, and there are no cloud or registry credentials in the repo or its workflows.
Names only - Your CI runner
A Meerkat key that works for this app and nothing else, replaced whenever the app is re-provisioned. Builds are brokered, so the runner never holds AWS, GCP or registry credentials. An app with a managed database also gets that one database's URL, for migrations.
One app - Secret values
Encrypted with AWS KMS at a separate path for each app and delivered only to that app, only for the keys it declares. Reading values back is rate-limited and written to an audit log.
Per app, audited - GitHub access
Installation tokens from a GitHub App you install and can remove at any time. GitHub expires each one within an hour.
Short-lived - Platform services
No long-lived AWS keys in any platform service. Each one gets temporary credentials from an IAM role of its own, so there is no master key sitting in a config file.
Temporary - Your terminal
blankcut login is approved in your browser, so no password passes through the terminal. We keep only a hash of the key it receives, and you can revoke it from the console. Releases ship signed checksums, which the installer checks.
Hashed, revocable
And on every release
Only declared keys reach the app
Your .env.example is the allowlist: a key it doesn't declare is refused when someone tries to set it, and never reaches the running app. Values are injected when the app starts, and server-side values are never passed to the build, so none of them end up baked into an image.
Allowlisted on write and at runtimeEvery release is reviewed
A release is a one-file change to your app's own deploy config, pinned to an image digest. A scope guard rejects anything outside that file, a reviewer checks the digest against what's live, and anything it isn't sure of waits for an engineer.
Fails closed to a humanScanned before the build, and after it
Your repo is checked for risky install steps, untrusted base images and dependencies from outside the registry, and the CLI looks for credentials committed to source before you push. Every image the platform builds is scanned for known CVEs before it's pushed, and everything running is re-scanned daily.
Source, build inputs and the running imageHardened containers
The Dockerfile we scaffold is multi-stage, slim and runs as a non-root user. Apps run with every Linux capability dropped, privilege escalation blocked and the runtime's default seccomp profile, so a compromised dependency has far less to work with.
No capabilities, no escalationTenant boundaries
Each customer runs in their own Kubernetes namespaces, with resource quotas sized to their plan so a runaway workload hits its own ceiling. Every console and API lookup is scoped to your organization; ask for another org's app and the answer is a 404.
Namespaces, quotas, org-scoped accessWatched around the clock
App health, restarts and logs stream into Meerkat continuously. Alerts reach you in the console and by email, and critical ones go to our platform team as well.
Alert rules evaluated continuouslyTwo ways to work
Wizard, terminal, or your coding agent.
Nothing in the platform is UI-only or CLI-only. Pick the surface that suits you, your teammate can pick the other one on the same app, and your agent can drive the same CLI you do.
I describe what I want
Guided flows, no terminal required
A short interview picks your path, then wizards handle GitHub, the starter repo, the database and the first deploy. Claude Code writes the app; we run it.
- Create a project in your GitHub account
- Import an existing repo
- Add a managed Postgres database
- Promote from a button, watch the rollout
I live in the terminal, or my agent does
One binary, scriptable end to end
Install the CLI, point it at a repo, and drive the whole pipeline from your shell, including the parts the wizard walks you through. Claude Code runs the same commands, and blankcut validate tells it what would fail before it opens a pull request.
blankcut validateblankcut promote --repo <url>blankcut provision --stack nextjsblankcut secrets push --app <app>blankcut status --app <app>Who it's for
If any of these is your Tuesday, we built this for you.
You ship with Claude Code or Cursor
TodayFeatures land in hours and then queue behind infra work nobody owns. Every session your agent invents a slightly different deployment.
With usA scaffolded repo with a CLAUDE.md your agent obeys, and one command from branch to reviewed production release.
You need a pipeline that runs without you
TodayEvery release is hand-driven, so shipping only happens when you are at the keyboard and remember the steps.
With usBuild, promote and roll back are automated and reviewable. The pipeline is the process, not a person.
You need production-grade security, early
TodayReal users are about to type real data into something you wired up over a weekend, and hardening it is still a list of things you meant to get to.
With usEncrypted secret store, key allowlisting, CVE-scanned and hardened non-root images, tenant isolation and a git audit trail, all on by default from day one.
You need to get to production, fast
TodayA prototype needs to be real by Friday and there's no time to stand up a platform first.
With usConnect GitHub, merge the scaffolding PR, promote the release. That's the whole path.
You have nobody to hand the infrastructure to
TodayThere is no ops person, and learning enough to feel safe about production is a project of its own on top of the app.
With usThe platform team is us. Cluster health, patching and alerting are ours. Your app is yours.
You ship apps for clients
TodayEvery engagement rebuilds the same pipeline, and handover means untangling your accounts from theirs.
With usEach client is a tenant with their own namespaces, billing and portal, and their repo already lives in their own account.
Rough Cut
New featureStaging, in miniature.
A Rough Cut is a small environment of its own: the same pipeline, the same scanning, its own namespace and resources, sized for something you are still figuring out. One per idea, rather than one big staging tier per company, at a flat $9.99 per month each.
Walled off from production
Its own namespace and its own resources. Whatever you break in here cannot reach the app your users are on.
Ships without the ceremony
Rough Cut releases merge on the automated scope guard alone, without the full deploy review, so the loop stays as fast as the idea.
A flat $9.99 a month
Per environment, not per hour. No compute metering and no overage to reason about, so a prototype that idles all week costs the same as one you hammer. Your plan caps how many you can run at once: 1 on Growth, 3 on Scale.
Pricing
A base fee, then what you actually use.
Compute is metered hourly against an included quota. Databases, domains and storage are per unit, and every invoice breaks down where it went. No seat maths and no surprise egress line.
Your first app in production, on real infrastructure.
556 CPU-hr
included, then $0.000050/CPU-sec
- Console and CLI, same capabilities in both
- Reviewed release pipeline with one-action rollback
- Encrypted secrets, CVE-scanned and hardened images
- Alerts in the portal and by email
A few apps in production, plus room to prototype.
1,667 CPU-hr
included, then $0.000045/CPU-sec
- Everything in Starter
- Up to 1 Rough Cut environment, $9.99 each
- 3x the included compute, at a lower overage rate
- Business-hours support window
Production workloads, and billing your own clients.
4,167 CPU-hr
included, then $0.000040/CPU-sec
- Everything in Growth
- Up to 3 Rough Cut environments, $9.99 each
- Largest included compute, lowest overage rate
- Stripe Connect billing for your own customers
High-capacity or regulated workloads, priced per engagement.
Per-customer metered rates.
- Negotiated per-deployment pricing
- Per-customer metered rates
- Rough Cut allowance set by your contract
- Direct line to the platform team
Every plan starts with a 14-day free trial.
No card to start: the trial includes one Rough Cut environment, enough to connect a repository and watch it deploy. Add a card and the trial opens up to production apps and managed databases on Starter, and nothing is charged until it ends. Your first invoice then covers the plan, plus any add-ons and usage past Starter's allowance during the trial. Switch plans any time. No card by the end and your projects pause; add one within 30 days to pick up where you left off.
On every plan: managed Postgres databases, managed domains, object storage and support hours an engineer logs are metered per unit, at the rates shown in your console before you add anything. Rough Cut environments are a flat $9.99 each per month. Compute overage past the included quota is billed at period end. Cancel any time, the repo and image are already yours.
Production infrastructure your AI-built apps can depend on.
Connect a repository and watch the scaffolding pull request open. No card to start, no sales call, and nothing lands on your default branch until you merge it.