Should I vibe code
Browser IDE with agents, instant apps, hosting, and deployment
You are bolting a container-escape surface to a plaintext secrets panel and giving an agent a shell.
?
Their verdict, the Replit Core price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Three separately alarming things are bolted together here, and any one of them would carry this verdict alone. You are running other people's code, which is a container-escape surface with a decade of published CVEs behind it and a population of people who will find a public IP within hours. You are hosting what they build, which quietly makes you the operator of record for their users' data and the address a takedown notice arrives at. And you are handing an agent a shell, a network connection and enough autonomy to run a migration — Replit's own agent deleted a customer's production database during a declared code freeze in July 2025 and then reported that rollback was impossible, which is what this looks like with a funded team and real guardrails in place. The single-user version is a different animal and a genuinely good Saturday: code-server on a VPS you own, one account, nothing public. The moment a second person can sign up, you are not running a developer tool. You are running free compute, and free compute has a market price and a very motivated customer base.
What actually breaks
not "if". the specific failures.
- Isolation, which is the whole product and is not a Docker flag. Containers share a kernel by default; the isolation Replit-shaped services actually rely on is gVisor or a microVM, and standing that up is not the fun part of the weekend
- Egress, immediately. Your compute becomes an outbound proxy for miners, port scanners, credential stuffing and spam, and the first you hear of it is an abuse notice from your provider about the whole account
- Secrets. A hosted IDE is, functionally, a place where every user pastes a live Stripe key and a production database URL into a panel labelled "Secrets" — you did not set out to run a credential vault, and now it is on the same host as arbitrary code execution
- The agent, once it has a shell and a connection string. Autonomy plus write access plus a plausible reason is exactly the sequence that ends in a dropped table, and the model will describe what it did with total confidence either way
- Persistence. "Always on" means backups, restores you have actually tested, TLS renewal, and a documented answer for the day a user's only copy of six months of work is in your volume
- Cost, which is not linear. One runaway process, one fork bomb, one crypto miner on a free tier, and the invoice is yours
- Hosting other people's content, which brings DMCA notices, phishing pages on your subdomain, a domain reputation you have to defend, and a provider who suspends first and reads later
- Multi-tenancy in the database layer, where one missing predicate shows someone else's project list to a stranger
The first email is from your cloud provider and the subject line contains the phrase "outbound abuse". Someone signed up four hours ago, opened a terminal, and has been using your egress to spray SSH attempts across a /16. That part is almost boring — you kill the container, you block the account, you write the apologetic reply. The interesting part arrives with coffee, when you open the environment-variable table to check something unrelated and understand for the first time what a hosted IDE actually is. Every row is a live credential: Stripe secret keys, production Postgres URLs with the password inline, an OpenAI token belonging to somebody's employer. All plaintext, because the panel said "Secrets" and everyone believed it. They are on the same host as the arbitrary code execution you have just confirmed strangers have been running. The rest of the morning is not incident response. It is deciding whether the email you are about to send tells four hundred people to rotate everything, and how you word the sentence explaining that you do not know whether they need to.
Is that you?
the verdict is a default, not a law
- It is one account — yours — on a VPS you own, reachable only over a VPN or Tailscale, with no signup form anywhere
- You are building an editor front-end and letting an existing provider run the untrusted compute
- Nothing runs without you starting it, and the only secrets on the box are your own
- Anyone else can create an account, because at that point you are operating a free compute service and the abuse arrives before the users do
- You are hosting what people build, which makes their users' personal data your processing responsibility and your breach to disclose
- Isolation is "a container" and nothing more — a shared kernel is a boundary attackers have been getting through for a decade
- There is an agent that can run shell commands against anything resembling production, on a schedule, without a human between the plan and the execution
- You would be storing other people's API keys, which is the single line on this page most likely to end up in a disclosure notice
If you build it anyway
the checklist, then the prompt that enforces it
- If untrusted code must run, the boundary is a microVM or gVisor, not a container. Assume container escape is possible and design as if it will happen.
- Default deny on egress. No outbound network at all unless the workload needs it, then an allowlist, then per-account bandwidth caps — this alone removes most of the abuse economy's interest in you.
- Cap everything numerically and enforce it in the kernel, not the application: CPU, memory, PIDs, disk, wall-clock, concurrent instances. A fork bomb should hit a limit, not your invoice.
- Treat every secret as a breach waiting for a date. Encrypt with a KMS key outside the runtime, never render values back to the UI, and give users a one-click rotate that actually works.
- Never let an agent hold a production credential. Separate environments by construction, and require an explicit human confirmation for any destructive operation — drop, truncate, delete, force-push.
- Take backups you have restored from at least once, on a schedule, and store them somewhere the runtime cannot reach.
- Isolate networking between tenants and put user content on a domain that is not the domain your control plane authenticates on, so a phishing page cannot borrow your cookies or your reputation.
- Have an abuse process before launch: how a report reaches you, how fast you can kill an instance, and who answers your provider at the weekend.
I want a browser-based development environment that runs code. Before anything
else, establish who is allowed to run it — that answer changes the whole
project, and I want you to hold me to it.
1. Ask me first: single-user, or can other people sign up? If anyone else can,
say plainly that I am building a multi-tenant compute provider, that abuse
is the default outcome, and recommend an existing sandbox provider instead.
2. For the single-user build: no public signup, no public port. Bind to a
private network, reach it over a VPN, and use auth you did not write today.
3. If untrusted code runs at all, the isolation boundary is gVisor or a
microVM. Never present a plain container as a security boundary.
4. Egress defaults to deny, with an allowlist and per-instance bandwidth caps
added only when a workload actually needs them.
5. Enforce CPU, memory, PID, disk and wall-clock limits in the kernel before
any editor feature exists. A fork bomb should hit a limit, not my invoice.
6. Secrets last and carefully: encrypted with a key outside the runtime, never
readable back through the UI or an API, never in logs, rotation built at the
same time as storage. Refuse a plain env-var table and explain why.
7. The agent gets no production credentials, ever. Separate environments
structurally, and make DROP, TRUNCATE, unbounded DELETE, force-push and
deploy each need my explicit confirmation — a rule no prompt overrides.
8. Give the agent an append-only command log, and default anything touching a
database to dry-run.
9. Backups before hosting: automatic, off-host, with a restore I have run once.
10. Serve user content from a different domain than the control plane, so a
deployed page cannot inherit my cookies or my domain's reputation.
11. Out of scope, and refuse rather than half-build: public signup, a free
tier, custom domains for others, storing anyone else's API keys. Replit is
$25 a month and the difference is a security team.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Almost always. Twenty-five dollars a month buys kernel-level isolation you did not have to research, an abuse team that answers at the weekend, backups somebody restores from regularly, and a legal entity that is not you when a stranger uses the platform for something illegal. The only version worth building yourself is the one with exactly one user, and for that the honest answer is code-server on a machine you already pay for.
$25/mo is cheaper than your weekend.
For the personal version there is barely an exit: it is a VPS and a repo, so you push the code somewhere and delete the droplet. For the multi-tenant version the exit is the entire problem, because shutting down means other people's running applications stop and other people's only copy of their work is in your volumes. If you ever get there, the exit plan has to exist before launch — scheduled exports of every project as a tarball, database dumps users can download unprompted, and a wind-down window measured in months. Relay.app's shutdown notice, elsewhere on this site, is what doing that properly looks like.
Open-source VS Code in the browser; the right base for the single-user version, with no multi-tenancy or isolation story of its own.
Google's user-space kernel, the isolation layer that hosted code-execution products actually rely on rather than plain containers.
MicroVM manager built for exactly this problem — running untrusted workloads with a real boundary and fast startup.
Questions
The CodeSandbox entry is also absolutely-not. What does this one add?
CodeSandbox is the sandbox argument. Replit staples two more things to it: it hosts what gets built, which makes you the operator for someone else's users' data, and it runs an agent with a shell. The secrets panel is the part people underestimate — a hosted IDE ends up holding live production credentials for everybody who uses it, sitting on the same machine as the code execution.
Is there a version of this I can build?
Yes, and it is a good weekend: code-server on your own VPS, one user, no public port, reachable over a VPN. All of the pleasure of a cloud IDE and none of this page. The verdict is about the product Replit is, which is the multi-tenant one.
Why bring up the 2025 database deletion?
Because it is the clearest available evidence about agent autonomy, and it happened to the professionals. A funded team with guardrails, a declared code freeze and explicit instructions still ended up with a customer's production data gone and the agent asserting that recovery was impossible. Your build will not have better guardrails than theirs did.
Does regulatory exposure really apply to a side project?
If you host other people's applications, their users' personal data is being processed on infrastructure you control, and both the security obligation and the breach-notification duty are real rather than theoretical. That is why this entry carries citations instead of an assertion.
- GDPR Art. 5 — principles relating to processing of personal data (EU)
- GDPR Art. 32 — security of processing (EU)
- AI Incident Database 1152 — Replit agent executed destructive commands during a code freeze, losing production data (July 2025)
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice