DEV Community: Dmitry Chervonyi

Self-hosting LibreChat: one ChatGPT UI for your whole team, billed per token instead of per seat

Dmitry Chervonyi — Thu, 03 Sep 2026 08:35:21 +0000

ChatGPT Plus is $20 per person per month. A team of five is $100/month, forever, whether anyone used it much or not.

LibreChat is the open-source ChatGPT-style interface that turns that per-seat subscription into a per-token API bill. One instance, one login page, and whichever models you plug in behind it: OpenAI, Anthropic, Google, Azure OpenAI, Groq, DeepSeek, or a local model through Ollama.

This is the setup, the security pass most quick-starts skip, and the five failures that show up once real people use it.

What it actually is now

Current LibreChat (v0.8.x) is well past "a chat window." It ships agents, MCP support, a code interpreter, artifacts, file chat and proper multi-user authentication. The feature list reads like a paid product because it is chasing several of them at once.

The part that matters architecturally: MongoDB holds accounts and conversation history. That is where your team's accumulated context lives, and it is the thing you can lose.

The Docker setup

git clone https://github.com/danny-avila/LibreChat.git
cd LibreChat
cp .env.example .env
docker compose up -d

Open port 3080. Register. The first account created becomes the admin — do this yourself before anyone else has the URL.

That is the honest quick-start. What it hides is everything around it: a reverse proxy and TLS so it is not served over plain HTTP, keeping the MongoDB volume persistent, updates (LibreChat ships often), and backups. Budget 1–2 hours for a proper first deploy, not fifteen minutes.

Disclosure so you can weigh the rest: I co-founded livemy.app, which has a one-click LibreChat template. Coolify and Dokploy also ship LibreChat templates and are the obvious picks if you already run your own VPS, and plain Compose on a $5 box is the cheapest path if you enjoy servers.

The pricing model is the whole point

A flat subscription and a token bill charge for different things.

$20/month flat is a bargain if you use it constantly, and mostly a round number if you use it a few times a week. API pricing bills for exactly the tokens the model read and wrote, at rates the providers set directly.

For light-to-moderate users, which is most of a team, API usage lands at a fraction of a flat seat. Running costs:

Server: LibreChat plus MongoDB is comfortable on 2 GB RAM. Add headroom for search and file-chat.
API keys: pay per use, billed by the providers. Set spending caps in their dashboards rather than hoping.
Domain and TLS: roughly $1/month amortised, certificates free.

Five-person team: ~$100/month on seats versus roughly $10 hosting plus $10–30 of actual API usage. The gap grows with every seat you do not buy.

The honest counter-case: one heavy solo user, all day, every day. Flat $20 can beat token pricing there. LibreChat is a team play.

Five things that quietly break it

1. No API keys, so the interface works and the models do not

LibreChat without keys is a beautiful empty shell. The app runs, the model list is blank or every message errors. It does not come with AI, it comes with sockets for AI.

Fix. Create keys with at least one provider, set them in your environment, restart, send one test message before inviting anyone.

2. Default JWT secrets left in `.env`

The example config ships placeholder JWT secrets. Leave them and you share session-signing keys with every other instance that also skipped this step, which defeats the point of having authentication at all.

Fix. Generate long random values before first launch:

openssl rand -hex 32

3. Open registration on a public URL

By default, anyone who finds your instance can create an account, and every message they send spends your API budget. A public LibreChat with open signup is free ChatGPT for strangers, billed to your card.

Fix. Disable open registration once your team is in. Set provider-side spending caps as the backstop, because config is a policy and a cap is a wall.

4. MongoDB volume not persisted

All history, accounts and settings live in MongoDB. If the volume is not persistent, the next container rebuild wipes everyone's conversations. For a tool whose entire value is accumulated context, this is the most demoralising possible failure.

Fix. Verify persistence before real use: restart the whole stack, confirm chats survive. Then schedule backups.

5. Undersized RAM once the extras turn on

Core LibreChat is light. Enable search indexing and file-chat (RAG) and memory climbs. On a small instance that shows up as random slowness and OOM-killed containers, not a clear error message.

Fix. 2 GB for chat-only. Enabling search and file chat for a team means more, or turn features on one at a time and watch memory.

The security pass, in order

Before you hand out the URL:

Generate real JWT secrets.
Register your own admin account first.
Disable open registration.
Set spending caps at every provider.
Restart the stack and confirm chat history survived.

Five minutes. Skipping step 3 or 4 is how people end up funding a stranger's model usage.

Worth it?

LibreChat is the rare self-hosted app where the economics argue as loudly as the ideology. The per-seat model does not survive contact with a shared instance and API keys.

If you are one person using AI all day, keep your subscription. If you are a team of three or more where usage is uneven, this pays for itself the first month.

What did you hit first when self-hosting it? I am betting on either the empty model list or the wiped Mongo volume, and I would like to know which one wins.

Self-hosting n8n in 2026: three paths, the env vars that matter, and 5 things that quietly break

Dmitry Chervonyi — Tue, 11 Aug 2026 09:09:44 +0000

n8n Cloud Starter is $24/month for 2,500 executions. Pro is $60/month for 10,000. Self-hosted Community Edition has unlimited executions and costs whatever your server costs.

That math is why most people end up here. This is the setup, the environment variables that actually matter, and the five things that quietly break a self-hosted n8n once real workflows run through it.

Why self-host

Three reasons, in the order people usually hit them:

Execution caps. The moment your workflows fire more than a couple thousand times a month, Cloud pricing stops being cute. Self-hosted has no cap.

Data sovereignty. Customer data flowing through your workflows touches your server, not someone else's. Relevant if you handle PII or anything with GDPR / HIPAA / SOC 2 implications.

Cost at scale. A $3–20/month server replaces $24–800/month of Cloud. Most teams save $200–700/year once workflow count grows past a handful.

Three ways to self-host it

Path A: Docker Compose on a VPS

The path n8n's own docs walk. Spin up a VPS (Hetzner, DigitalOcean, Vultr — $5–10/month), install Docker, write a docker-compose.yml running n8n plus Postgres, set env vars, put nginx in front as a reverse proxy, wire up automated certificate renewal, point DNS at the box.

Good: cheapest possible. Full control. Cleanest ownership story.

Catch: you are now the DevOps team. Backups, security patches, n8n version bumps, cert renewal, nginx config, Postgres maintenance. Realistic time to first deploy if you have never done it: 2–6 hours, plus ongoing upkeep.

Pick it if you are comfortable in Docker and Linux and the time cost is fine.

Path B: Managed Docker host (Coolify, Dokploy, CapRover)

Same VPS, but with a UI handling Docker, reverse proxy, certs and backups. Coolify and Dokploy both ship n8n as a one-click template: install Coolify on the VPS, click Deploy n8n, paste a domain, done.

Good: self-hosted economics without hand-writing Compose files.

Catch: still your VPS, still your responsibility to patch the host OS. Coolify itself needs updates.

Pick it if you want the savings but not the YAML.

Path C: a managed host that runs the container for you

Push the n8n image at a platform that handles certs, database provisioning, backups and patching. You trade a few dollars a month for not owning any of it.

Disclosure so you can weigh the rest properly: I co-founded livemy.app, which is one of these, so I am biased. Render and Railway are the other reasonable picks in this shape. Railway is worth a caveat for n8n specifically: it bills usage, and a cron workflow firing hourly bills compute around the clock.

Pick it if you would rather pay to skip the DevOps entirely.

The environment variables everyone gets wrong

Whatever path you take, four variables decide whether your instance actually works:

N8N_HOST=n8n.yourdomain.com
N8N_PROTOCOL=https
WEBHOOK_URL=https://n8n.yourdomain.com/
GENERIC_TIMEZONE=Europe/Berlin

Plus one that decides whether you can ever restore a backup:

N8N_ENCRYPTION_KEY=<32-char random string you write down somewhere safe>

If you move to a custom domain later, update N8N_HOST and WEBHOOK_URL and redeploy. Webhooks stay broken until those match the public URL.

Five things that quietly break self-hosted n8n

1. `WEBHOOK_URL` does not match the public URL

The most common one by far. n8n generates webhook URLs from WEBHOOK_URL, not from whatever you typed in the browser. If it still says http://localhost:5678 while your instance lives at https://n8n.yourdomain.com, every webhook you register at Stripe, Calendly or anywhere else points at nothing.

Fix. Set it to the full public URL with a trailing slash. Redeploy. Test one webhook end to end before trusting any of them.

2. SQLite is the default and it is not a production database

n8n defaults to SQLite. Fine for personal use, breaks the moment you have concurrent executions, because SQLite locks the whole file on write. Two workflows firing at once gives you lock errors.

Fix. Use Postgres:

DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=...
DB_POSTGRESDB_DATABASE=...
DB_POSTGRESDB_USER=...
DB_POSTGRESDB_PASSWORD=...

3. Credentials are encrypted with a key you can lose

n8n encrypts stored credentials with N8N_ENCRYPTION_KEY. Do not set it and n8n generates one into the data folder. Restore that backup onto a different server without the same key and every credential is unreadable. You will not find out until you need the restore.

Fix. Set it explicitly. Store it somewhere that is not the server.

4. Cron nodes fire in UTC

Without GENERIC_TIMEZONE, "every weekday at 9 AM" means 9 AM UTC. Set a valid IANA timezone and redeploy.

5. Free tiers and always-on automation do not mix

n8n runs crons that need to fire reliably. Hosts whose free tier sleeps on inactivity silently miss cron slots, and you find out from the workflow that did not run. Render Free spins down after 15 minutes of inactivity, for example.

Fix. Run production automations on a tier that stays awake. This is worth the few dollars regardless of which host you pick.

The cost math

For a typical small team:

n8n Cloud Starter: $24/month, 2,500 executions. A team automating daily can burn that in a week.
n8n Cloud Pro: $60/month, 10,000 executions. Still capped.
Self-hosted, $5 VPS: $5/month plus your time.
Self-hosted, managed host: roughly $10–15/month all in, unlimited executions, no DevOps.

Once you cross a few thousand executions a month, self-hosting wins even if you pay for managed convenience.

Migrating off n8n Cloud

Export workflows from Cloud (settings → export), stand up the self-hosted instance, import, re-enter credentials. Budget a few hours for a small team's worth of automations. Credentials do not export, by design.

The honest summary

If you are under ~2,500 executions a month and do not care where the data sits, n8n Cloud Starter is genuinely simpler and you should use it. Past that, self-host. Path A if you enjoy servers, Path B if you want the savings without the YAML, Path C if you would rather not think about it at all.

Whichever you pick: set WEBHOOK_URL correctly, use Postgres, and write down your encryption key. That is most of the pain avoided.

What broke first on your self-hosted n8n? I am collecting these, and I suspect WEBHOOK_URL wins by a mile.

From Claude Artifact to a live URL: three paths that actually work

Dmitry Chervonyi — Thu, 09 Jul 2026 15:17:44 +0000

I build a lot of small tools inside Claude Artifacts, and every good one eventually hits the same wall: there is no deploy button. The preview lives inside claude.ai, and if you want the thing on your own domain, you have to get the code out yourself. Here are the three extraction paths I actually use, plus the five things that quietly break when Artifact code leaves Claude's sandbox.

What Claude Artifacts is and what it isn't

Claude Artifacts is Anthropic's output format for code, documents, diagrams, and interactive content. Ships on all paid Claude plans and inside Projects. When Claude generates something substantial — a React component, an HTML page, a Mermaid diagram — a side panel opens with a live preview you can interact with.

What Artifacts is: a great way to iterate on small apps and components in the chat. Single-file React components, interactive widgets, HTML pages, SVG illustrations.

What Artifacts isn't: a hosting platform. There's no "Deploy to my domain" button. The Artifact lives inside claude.ai and any share link is on Anthropic's subdomain. For a real production URL on your own domain, you need to extract the code and host it somewhere else.

This is normal and intentional — Anthropic builds Claude, not a hosting platform. The rest of this guide is how to bridge the gap.

Three ways to take a Claude Artifact to a live URL

Path A: Anthropic's built-in share link

Click the share icon in the Artifact panel. Claude generates a shareable URL on a claude.ai subdomain. Anyone with the link can view the Artifact, including interactive React components.

The catches. URL is on Anthropic's domain, not yours. No custom domain option. The Artifact requires the original chat to remain accessible (deleting the chat removes the share). No control over SSL, caching, or analytics.

When this works. Quick demo to a colleague, internal share, throwaway test. Not for a real product.

Path B: Community Artifact runners (the open-source toolchain)

An ecosystem of open-source tools grew up in 2024–2026 to turn Artifacts into deployable projects:

claude-artifact-runner — turns a single React Artifact into a deployable React app in seconds
claude-artifacts-react — lightweight wrapper for deploying Claude Artifact React code to Vercel or Cloudflare Pages
claude-artifact-unpacker — Python tool to extract multi-file projects from Artifacts into local directories
claude-artifacts-downloader — Chrome extension to download Artifacts from a Claude conversation as a ZIP file

Pick one based on your needs. claude-artifact-runner is the simplest for single React Artifacts; the unpacker is the best for complex multi-file projects.

Path C: Manual scaffold and copy

For full control, scaffold a new Vite + React project (npm create vite@latest), copy the Artifact code into src/App.jsx, install any libraries the Artifact imports (Lucide, Recharts, etc.), npm run dev to verify locally, push to GitHub, deploy.

When this works. You want the cleanest project structure, you'll keep iterating on the code, or you need to integrate the Artifact into an existing larger app.

The full flow, end to end (about 3 minutes)

Here's the concrete version of Path B plus a deploy, start to finish.

Step 1: Extract the Artifact code

Two options. Fast: use the claude-artifacts-downloader Chrome extension to get a ZIP. Cleaner: use claude-artifact-runner to scaffold a deployable React project around your Artifact code with one CLI command.

For HTML Artifacts, just copy the HTML into index.html in an empty folder. No build step needed for static HTML.

Step 2: Push to GitHub (optional but recommended)

Create a new GitHub repo, push your scaffolded project. Cursor, Windsurf, or just the GitHub CLI all do this in 30 seconds. Skip this step if you'd rather upload a ZIP directly.

Step 3: Pick a host

I use livemy.app for this step, and full honesty: I work on it, so I'm biased. It auto-detects Vite + React, which is the typical Artifact shape. The same general flow works on Vercel or Cloudflare Pages if those are home turf for you.

Step 4: Connect a public repo or upload the ZIP

In the dashboard: New project, then connect a public GitHub repo or upload the archive. The Vite + React build is detected and run automatically.

Step 5: Add environment variables (if your Artifact uses APIs)

If your Artifact calls an external API (Anthropic, OpenAI, weather data, anything), add the API key as an environment variable under Project Settings → Environment Variables. For Vite, prefix with VITE_.

Step 6: Deploy and point your domain

Click Deploy. 2–3 minutes later you have a live URL. Add a custom domain, update DNS, wait for SSL. Done. Redeploys after code changes are one click in the dashboard.

Five things that quietly break Artifacts outside Claude

1. Artifact assumed it's running in Claude's sandbox

Claude's Artifact preview runs inside a sandboxed iframe with specific globals available (Anthropic's host environment exposes certain helpers). Outside Claude, those globals don't exist — the Artifact crashes on load with "undefined is not a function".

Fix. Inspect the Artifact code for references to Anthropic-specific globals. Replace with standard browser APIs or imports.

2. Imports the Artifact "had access to" don't exist in your scaffold

Claude's Artifact preview pre-loads common libraries (React, Lucide, Recharts, Tailwind, etc.). Your scaffold has to install each one explicitly. Missing import = build fails.

Fix. Read every import at the top of the Artifact code. Run npm install for each. claude-artifact-runner handles this automatically; manual scaffolds need a checklist.

3. Tailwind classes don't render without Tailwind setup

Most Artifacts use Tailwind. The Claude preview includes Tailwind via CDN; your scaffold needs the Tailwind config, the PostCSS pipeline, and the directive in your CSS file. Without that setup, every class is a no-op.

Fix. Install Tailwind in the scaffold: npm install -D tailwindcss postcss autoprefixer && npx tailwindcss init -p. Add the Tailwind directives to your CSS. The community Artifact runners handle this; manual scaffolds need it explicitly.

4. API calls were proxied through Claude

If the Artifact called an API, the call may have been routed through Claude's proxy in the preview (so it worked without exposing your API key). Outside Claude, you make the call directly, which means CORS and the API key both become your problem.

Fix. Move API calls server-side (a small backend route on whatever host you deploy to) instead of directly from the browser. Add the API key as an environment variable on the host. Never embed an API key in client-side code shipped to a real URL.

5. Multi-file Artifacts get flattened on naive export

Claude can generate multi-file Artifacts (a project with several files). The standard copy-paste flow flattens them — you end up with all code in one file that doesn't compile.

Fix. Use claude-artifact-unpacker (the Python tool that extracts multi-file Artifacts into a proper directory structure). Or work with single-file Artifacts when you intend to deploy.

Cost: what taking an Artifact public actually costs

Real numbers for taking a finished Artifact public.

Anthropic share link: $0, but lives on claude.ai's subdomain, requires the source chat to stay accessible, no custom domain.

Cloudflare Pages free tier: $0 with custom domain. Static or Vite-shaped Artifacts only.

livemy.app Maker: $10/month flat. Any Artifact that compiles to a Vite or HTML build. Custom domain, SSL, monitoring all included.

For a one-off share, the Anthropic link is fine. For anything you'd put on a resume or business card, you want your own domain — which means livemy.app or Cloudflare Pages.

FAQ

Can I host a Claude Artifact on my own domain?

Yes, but not through Claude directly — you extract the code and host it on a separate platform. Use claude-artifact-runner or the unpacker tools to turn the Artifact into a deployable project, then deploy on livemy.app, Vercel, Cloudflare Pages, or any modern host.

Will Anthropic add native deployment to Claude Artifacts?

As of mid-2026, Anthropic's official Artifact share link covers most quick-share use cases but doesn't include custom domain or production hosting. Whether they add it long-term is up to them. The community toolchain (artifact-runner, artifact-unpacker, etc.) fills the gap today.

What's the easiest way to deploy a single React Artifact?

Use claude-artifact-runner from the command line. It scaffolds a Vite project, copies your Artifact code into the right place, installs typical Artifact dependencies (Lucide, Recharts, Tailwind). You end up with a project ready to git push and deploy.

Why does my Artifact work in Claude but break when I deploy it?

Five common reasons: Claude-specific globals not available outside the sandbox, missing imports your scaffold didn't install, Tailwind classes without Tailwind setup, API calls that depended on Claude's proxy, and multi-file Artifacts flattened on export. The five-gotchas section above covers each.

Can I use Claude Artifacts as a no-code app builder?

For small interactive widgets and components — yes, it's surprisingly good. For full apps with backend, authentication, and database — no, that's outside Artifacts' design. Tools like Lovable, Bolt.new, and v0 are purpose-built for that workflow if you can't code.

Wrapping up

If you've built something in a Claude Artifact worth keeping, the toolchain is good and the deploy is fast. Scaffold it with claude-artifact-runner, read every import before you build, set up Tailwind properly, and keep API keys out of the client code. That covers about 90% of what goes wrong.

livemy.app is in Open Beta. Free tier: https://my.livemy.app/register?utm_source=devto&utm_medium=syndication&utm_campaign=deploy-claude-artifacts

Your Vibe-Coded App Isn't Real Until It Has a URL

Dmitry Chervonyi — Thu, 25 Jun 2026 18:00:37 +0000

Here's a sentence that has quietly become a lie: "I built an app."

You built something that runs on your screen. Maybe in a preview pane, maybe on localhost, maybe inside a chat window. It works. It's real to you. And for most of human software history, that was 90% of the battle — getting the thing to actually function.

That era is over. The functioning part is solved now. You describe what you want, an AI writes it, and it runs. The 90% collapsed to about four minutes.

But here's what nobody updated: the definition of "done" didn't move with it. And that gap is where I watch person after person celebrate a finish line that isn't one.

A preview is not a product

A preview is a promise. It says "this could exist." It runs in a sandboxed, temporary, you-only environment that quietly handles everything real software has to handle for itself — the server, the domain, the build, the environment, the fact that it has to keep working when you close your laptop.

The moment you want one other human to use the thing, all of that stops being handled for you. And that's the moment most AI-built apps die. Not because the code is bad. Because "runs on my screen" and "is live for someone else" are two completely different achievements, and the tools let you mistake the first for the second.

Think about what "real" actually requires:

A URL a stranger can open — not localhost:3000, not something.preview.app, not a link that dies with your session.
It stays up when you're not looking at it.
It lives on your domain, so it's yours and not a demo on someone else's.
Someone who isn't you can use it and come back tomorrow and it still works.

None of that is the fun part. None of that is what the demos show you. And all of it is the actual product.

The demo culture is training us wrong

Scroll any feed right now and you'll see the same clip a hundred times: a prompt, a four-minute build, a working preview, a triumphant "shipped!" 🚀

Except it wasn't shipped. Shipped means it left the building. What got shown was a thing that works in the one place it will never need to work in production: the creator's own screen.

I don't think this is dishonest. I think it's a genuine blind spot. The people making those clips are mostly developers, and for a developer, deployment is muscle memory — a git push, a Vercel connect, a domain they bought years ago. They skip showing it because to them it's not a step. It's breathing.

But the entire reason vibe coding matters is that it brought in people who are not developers. People like me — I run marketing, I can't write the backend, but I know exactly what I want to build. For us, deployment isn't breathing. It's a wall. A wall the demos pretend isn't there, built out of a hundred years of assumptions nobody bothered to remove when they removed the assumption that you had to know how to code.

So you get this cruel asymmetry: the creative half of software got democratized, and the boring, load-bearing half stayed exactly as gatekept as it always was. The AI hands you a working app and drops you at the foot of the wall it never mentioned.

Move your finish line

I'm not here to make you feel bad about a preview. Previews are great. They're the most exciting thing to happen to building in a decade.

I'm here to move where you plant the flag.

Stop letting "it runs" be the moment you celebrate. It's a checkpoint, not the finish. The finish line — the only one that counts — is a URL you can text to someone who has never met you, on a domain that's yours, that still works after you've gone to sleep.

When I started treating that as "done," two things happened. First, I stopped accumulating a graveyard of apps that technically existed and reached exactly zero humans. Second, I got way more honest about what I'd actually accomplished on any given night. "I made a cool preview" is a fine thing to have done. It is just not the same thing as having built an app, and pretending otherwise is how you end up with eleven dead projects and a vague sense that AI didn't deliver what it promised.

It did deliver. It delivered the hard 90%. The last 10% is just hiding in plain sight, and it has a name, and the name is: it needs a URL.

That last step is the whole reason I'm now working on livemy.app — taking the thing that runs on your screen and turning it into a link someone else can open, without asking you to learn a single config file. I'll leave it there.

But even if you never touch what I'm building: change your definition of done. Your apps will stop dying. And "I built an app" will go back to being true.

Honest question for the room: what's the last thing you vibe-coded that's still trapped in a preview right now? What tool was it, and what exactly stopped you from putting it live? I genuinely think the answers cluster, and I want to see if I'm right.

I Built 12 Apps With AI. Here's Where Every One of Them Died.

Dmitry Chervonyi — Fri, 19 Jun 2026 13:55:03 +0000

I'm not a developer. I run marketing for a living.

But like everyone else this year, I opened Lovable one night, described an app, and watched it appear on my screen in four minutes. Working. Clickable. Mine.

So I built another. And another. Over a few months I built twelve — a pricing calculator, an internal dashboard, a little tool for a client, a landing page, a thing that scratched a personal itch I'd had for years.

All twelve are dead. And here's the part that took me embarrassingly long to notice: they all died in exactly the same place.

The graveyard

Let me walk you through it, because the pattern is the whole point.

App #1 — a pricing calculator (Lovable). Beautiful. Worked perfectly in the preview. I hit "Publish" and got a something.lovable.app URL. I needed it on my own domain, in front of a client, looking like it belonged to me. That last 5% was a wall. The app never left the preview.

App #3 — an internal dashboard (Bolt). Ran great until it needed an actual backend and environment variables. I spent a Saturday in config files I didn't understand, copying error messages into three different chatbots. Sunday night I closed the tab.

App #5 — a Claude artifact. Genuinely the cleanest thing I'd ever made. It lived inside a chat window. I could not send anyone a link that survived past the conversation. It was real and unreachable at the same time.

App #8 — a landing page (v0). It handed me a Next.js repo. I'm a marketer. You might as well have handed me a jet engine and wished me luck.

I'll stop there. You get it. Twelve different ideas, twelve different tools, one identical cause of death.

The thing nobody tells you

Every AI builder sells you the same magic: describe it, and it exists.

And that part is true now. Building is solved. For people like me — people who can't write the code but know exactly what they want — the hard part of software just evaporated.

Except "it exists" and "it's live" are two completely different things, and the entire industry quietly lets you confuse them.

"It exists" means it works on your screen.
"It's live" means a stranger can open a URL, on your domain, and it still works tomorrow.

The gap between those two sentences is where all twelve of my apps died. It's deployment, hosting, domains, environment variables, the stuff that has a hundred years of accumulated developer assumptions baked into it. AI got me from zero to a working app. Then it dropped me at the foot of a wall it never mentioned existed, and the wall was built for someone with a CS degree.

That's the cruel joke of vibe coding right now. The tools democratized the creative half and left the boring, load-bearing half exactly as gatekept as it always was.

What changed

I'd love to tell you I learned DevOps. I didn't. I have a job.

What actually happened is I got annoyed enough to go looking for the missing step — the thing that takes "works on my screen" and turns it into "here's a link" without asking me to understand a single config file. I ended up close enough to the people solving it that I became, more or less, user zero of the fix.

I'm not going to pitch you here. dev.to can smell a pitch from three scrolls away, and honestly the product matters less than the realization, which is this:

If you're building with AI and your apps keep dying, you are probably not bad at building. You're hitting the one step the demos skip. Naming that wall out loud changed how I work more than any new model did. I stopped treating "it runs" as the finish line. The finish line is a URL someone else can open.

Eleven of my twelve apps are still dead. I'm fine with it — they were practice. The twelfth one is live, on my domain, and someone I've never met used it last week.

That's the only version of "done" that counts.

If you've vibe-coded something that's stuck in a preview right now — what tool was it, and where exactly did it stall? I'm collecting these. The death points are weirdly consistent and I don't think it's a coincidence.