MeerkatQuestions
The ones people actually ask.
If something here is unclear, or you have a question we haven't answered, say so and we will add it.
Getting started
Where does my code live?
In your own account, from the first minute. We connect through an app you install and can revoke, and we never host your repository. GitHub is supported today, with GitLab and other hosts on the way. If you stop paying us tomorrow you still have a working, buildable app.
What's actually running underneath?
Containers on Kubernetes, with ArgoCD reconciling each reviewed release. You never have to touch any of it, and you never have to learn it to ship. The surface you work with is a repo, a pull request and a promote button, and the console will show you the layer underneath whenever you want to look.
What if my repo has no Dockerfile?
Then the scaffolding PR writes one for you: multi-stage, slim runtime, non-root, no build toolchain in the final image, along with the build workflow, deploy manifest and a declaration of the keys your app may read. You review it like any other pull request.
What is a Rough Cut environment?
Staging in miniature: a small environment with its own namespace and resources, running the same pipeline and the same scanning as production, meant for an idea you are still testing. Its releases merge on the automated scope guard alone rather than going through the full deploy review, so iteration stays quick. Each one is a flat $9.99 a month, with no compute metering, and your plan caps how many run at once: one on Growth, three on Scale, and whatever a custom contract says.
Security
What do you check before something ships?
Two passes. Before the build, your repo is scanned when it onboards and again on each release: Dockerfiles that pipe a downloaded script into a shell, base images pulled from registries outside our allowlist, and package manifests with install hooks that reach the network or dependencies sourced outside the registry. The CLI runs the same checks locally, plus a check for credentials committed to source, so you or your agent see a finding before pushing. Images built through the platform's build service are scanned after the build and before the push, for known vulnerabilities that have a published fix, and every image you are running is re-scanned daily, so a vulnerability published after your build still surfaces. The findings appear on each app's Security panel, grouped by the package upgrade that fixes them, and your coding agent can read the same list with blankcut scan (CLI v0.20.0 and later). Fix them yourself, ask our team to (billed as support time), or request a reviewed waiver for one you cannot fix yet. Blocking is being switched on one app at a time: a build that carries an unwaived critical or high finding stops before the push, so it cannot deploy. It is already on for the apps we run ourselves, and you hear from us before it is switched on for yours; until then your findings are reported, not enforced. Images are digest-pinned on the way out, so the thing scanned is the thing that runs.
How do secrets work, exactly?
Values are encrypted with AWS KMS, stored at a separate path for each app, and injected when the app starts. Your repo's .env.example declares which keys are permitted, and that declaration is an allowlist: a key it never declared is refused when someone tries to set it and never reaches the app. Server-side values are never passed to the build, so none end up baked into an image; the console passes them through without storing them, and reading values back is rate-limited and written to an audit log. Nothing sensitive is ever committed.
Is my app isolated from other customers?
Each tenant gets their own Kubernetes namespaces, with resource quotas sized to their plan so a runaway workload hits its own ceiling. Credentials are separate too: secret values sit at a per-app path and reach only that app, and the key in your CI works for your app alone. Every console and API lookup is filtered to your organization, so asking for another org's app returns a 404. Apps run on a shared, hardened cluster rather than a dedicated one per customer.
If Meerkat itself were breached, what would an attacker get?
As little as we can arrange. We design around that question rather than assume it away. Our databases hold API keys and sign-in links only as hashes and passwords only as bcrypt hashes, so a copy of them holds nothing anyone could sign in with. Secret values aren't in those databases at all: they are encrypted with AWS KMS in a separate store, at a separate path for each app. Platform services hold no long-lived AWS keys, GitHub access runs on tokens that expire within an hour, and the key in your CI works for one app. None of that makes a platform unbreachable, and we won't claim it does. It means one stolen credential opens one door, not all of them.
Working with agents
Can my AI agent break production?
It can open pull requests and run blankcut promote, which is as much power as any teammate has. Every release is a one-file change to its own app's deploy config: a scope guard rejects anything outside that file, our deploy reviewer checks the pinned image against what is live, and anything the reviewer isn't sure of waits for one of our engineers. Releases are diffs, and rollback is one action. The CLAUDE.md in the repo keeps its suggestions inside the platform's architecture in the first place.
Can I just have my agent deploy to my own cloud account?
You can, and it will often work. The trouble is what you cannot see: instances sized for nothing in particular, no quotas, no probes, no alerting, and a setup nobody can maintain in three months. Going through us costs you a base fee and gives you sizing, scanning, review and a rollback path that were decided before your agent typed anything.
Do I have to use the CLI?
No. Every action exists in the console and in the CLI, so you can drive the wizard, live in your terminal, or let Claude Code run the commands for you. Your teammate can pick a different surface on the same app.
Money and leaving
What does it cost to start?
Plans start at $25 a month with an included compute quota, and every account starts with a 14-day free trial. Managed databases, domains, object storage and logged support hours are metered per unit at the rates shown in your console, Rough Cut environments are a flat $9.99 each per month, and compute past the quota is billed at period end.
Do I need a card for the free trial?
Not to start. Without a card the trial includes one Rough Cut environment, enough to connect a repository and watch it build and deploy. Add a card and the rest of the trial opens up to production apps and managed databases on the Starter plan, and nothing is charged until the trial ends. Your first invoice then covers the plan, plus any add-ons (a managed database, say) and compute past Starter's included allowance used during the trial. You can move to Growth or Scale any time from Billing. If the trial ends without a card, your projects pause rather than disappear, and adding one within 30 days brings them back.
What happens if I outgrow you?
You take the repo, the image and the manifests. All standard, all already in your possession. We would rather be left cleanly than hold anyone hostage.
Still deciding?
The trial needs no card to start, and nothing lands on your default branch until you merge it.