Web basics for vibe coders: from localhost to production

The moment AI finishes your app

You open a chat window. You describe a todo app. Twenty minutes later you have working code on your laptop. You click, it works. You click again, it works. Then you hit the wall every vibe coder hits:

"How do my friends actually use this?"

The demo lives at http://localhost:3000. That address points to your laptop, only. Close the tab, kill the process, turn off the Wi-Fi — it's gone. To make the app live on the real internet, you need a handful of ideas that AI tutorials usually skip. This guide walks you through them in plain words. It also flags one security trap most tutorials miss.

The whole stack as one restaurant

A web service is a restaurant. Keep that picture in your head and the rest below slots into place:

Each bold word maps to a section below. The analogy will break down sooner or later — real restaurants don't have copy-paste APIs — but it's a good scaffold for the first month.

Client and server

The client is whoever makes the request. "Please give me the todo list page." That's usually a browser, sometimes a mobile app, rarely a terminal. One client, one person, one request at a time.

The server is the machine that answers. It's a computer, always on, somewhere on the internet, waiting to be asked. One server, many clients at once — sometimes millions.

When you type tene.sh into your browser and hit enter:

1. Your browser (client) asks the server at tene.sh for a page
2. The server builds a reply and sends it back
3. Your browser paints it on screen

That single round-trip, repeated a million times a day, is the whole web.

Frontend and backend

These are two halves of what you write. The split is about audience more than about tech.

Frontend is every pixel the user sees. Buttons, layout, colors, animations, the error message when they typo their email. It runs inside the user's browser. The main languages are HTML, CSS, and JavaScript, plus one of the JavaScript frameworks — React, Vue, or Svelte — and a meta-framework on top, usually Next.js or Nuxt.

Backend is everything the user doesn't see. Checking that the password is right. Working out the monthly invoice. Writing the row to the database. Sending the email. It runs on a server you own, not in the user's browser. Languages range widely — Node.js, Go, Python, Ruby — but the patterns are similar.

The split matters because the browser is hostile ground. Any code you put in the frontend, any API key you ship to the browser, any database query you "temporarily" run from client-side code — a curious user can see all of it in 10 seconds with Chrome DevTools. Anything sensitive belongs on the backend.

The database

If the backend is the kitchen, the database is the fridge. It's where data lives between requests.

A relational database (SQL) stores data in tables, like a very fast spreadsheet that never corrupts and handles a million users at once. Columns have types. Links between tables are clear and explicit. PostgreSQL, MySQL, and SQLite are the three names you'll hear most.

A document database (NoSQL) stores data in flexible, nested documents — closer to JSON than to Excel. MongoDB is the famous one. DynamoDB and Firestore are the cloud-native cousins.

For a first app, pick SQLite or PostgreSQL. They're well documented, cheap, boring in the good way, and AI coding helpers write correct SQL for them out of the box. Exotic databases are a choice for version 2.

File storage

Databases are bad at big files. A 40 KB profile is fine inside a user row. A 4 MB profile photo is not. Binary files (images, videos, PDFs) go into object storage, separate from the database.

AWS S3 is the original. Cloudflare R2, Backblaze B2, Google Cloud Storage, Azure Blob Storage — all the same idea. You get a bucket, you upload files to paths inside it, you get back URLs. Your backend saves the URL in the database. The user's browser fetches the file straight from the storage service.

A key detail for later: every one of these services needs an access key to write to your bucket. That key must never end up in the frontend. Never. This is where secret management starts to matter.

Network and HTTPS

HTTP is the protocol of the web. Browser asks, server replies, in plain text over the internet. The problem: anything in plain text can be read by anyone in the middle — your Wi-Fi router, your ISP, any bad actor on the path.

HTTPS is HTTP wrapped in encryption. The S is for Secure. When your browser shows the padlock icon, you're on HTTPS. The math is strong (TLS 1.3, usually) and, for someone sniffing the Wi-Fi, unreadable.

Two rules for 2026:

1. Everything is HTTPS. Browsers warn users about non-HTTPS sites. Search engines push them down the rankings. There's no excuse. Let's Encrypt hands out free certificates, and every deploy platform (Vercel, Netlify, Fly, Railway) turns on HTTPS by default.
2. HTTPS doesn't protect the secret on your server. Anyone who breaks into your server reads your secrets in the clear, TLS or not. HTTPS guards the wire, not the fridge.

You also need a domain name — the human-readable address. A DNS record turns tene.sh into an IP address like 76.76.21.21. Registrars (Namecheap, Cloudflare, Porkbun) sell domains by the year. DNS is usually handled by your deploy platform or by Cloudflare.

Where the HTML comes from: CSR vs SSR

One frontend detail confuses newcomers. There are two ways to build the HTML the browser sees:

• CSR (Client-Side Rendering): Server ships a mostly empty HTML file plus a big JavaScript bundle. The browser runs the JS, which builds the page in memory. Quick to jump between pages. Slow on first load. Bad for SEO unless you add more machinery.
• SSR (Server-Side Rendering): Server builds the HTML ahead of time and ships it complete. The browser paints it right away. Quick first load. Good for SEO. A bit more server work per request.

Next.js and Nuxt default to a hybrid: SSR for the first page load, CSR for the next clicks. That's usually what you want. For a pure marketing site or blog, static generation (SSG — pre-build all pages to files) is even quicker.

Infrastructure

Everything above is code. Infrastructure is the hardware and config that runs it. You rarely touch it now, but it's what your bill pays for.

The modern default is cloud infrastructure. You don't buy servers. You rent capacity from AWS, Google Cloud, or Azure. Better still, you ride a platform on top of the cloud — Vercel, Netlify, Fly.io, Railway — that hides almost all of it. You push code. The platform works out where to run it.

For a first deploy, pick a platform. The day you do something very custom (a specific database engine, GPU jobs, multi-region failover), you drop down to the cloud directly. Most apps never need to.

Deployment

Deployment is the act of taking code from your laptop and making it live on the internet. The modern flow looks like this:

1. You write code on your machine and commit it to Git (version control).
2. You push the commits to GitHub (or GitLab, or similar).
3. Your deploy platform watches your GitHub repo.
4. It sees a new commit, runs a build (compiles, bundles, minifies), and copies the output to its servers.
5. It swaps your new version in. Users start hitting the new code.

Three environments are common:

• Development: your laptop. Breaks allowed.
• Staging: a copy of production your team can test against before shipping. Breaks now and then.
• Production: the real one. Real users, real money, no breaks.

A healthy flow: push to a branch, automatic staging deploy, eyeball it, merge to main, automatic production deploy.

The Vercel shortcut

Vercel deserves its own mention because it turns the whole deploy chapter into three clicks. Push your code to GitHub, connect the repo to Vercel, merge to main — live on the internet, HTTPS included, global CDN included.

For Next.js or React apps, it's the path of least resistance. For heavier backends (long-running servers, GPU jobs, big database migrations), Vercel is the wrong answer. Fly.io, Railway, or a proper AWS setup fit better. Pick the tool that fits the shape of your app, not the most-hyped one.

The security gap every vibe coder hits

Here's the paragraph most "deploy your first app" tutorials skip.

Your app almost certainly reads environment variables from a .env file: STRIPE_KEY=sk_live_..., OPENAI_API_KEY=sk-..., DATABASE_URL=postgres://.... That file sits at the root of your project, in plain text.

Three things then happen that tutorials don't warn you about:

1. Your AI coding helper reads it. Claude Code, Cursor, Windsurf, Copilot — all of them index project files for context. .env is a file in the project. It gets included. Your API keys end up inside the model's context window on every request, and sometimes in chat logs.
2. You commit it by mistake. One git add . at 2 a.m., a misread .gitignore, a forgotten path — the keys are now on GitHub. GitHub's secret scanner catches most, but not all.
3. You paste the key somewhere while debugging. A Discord channel, a Stack Overflow question, a screenshot in a slide deck. One slip is all it takes.

Any one of the three is enough for an attacker to start billing your credit card against your OpenAI account.

The fix is structural: never let the plain .env exist on disk in the first place. Encrypt the secrets at rest, decrypt them in memory only, and pass them to your app as environment variables at runtime. That's the pattern tene uses:

# 1. Install once
curl -sSfL https://tene.sh/install.sh | sh

# 2. Import your .env, then delete the plain file
tene import .env
rm .env

# 3. Run your app — secrets injected as env vars at runtime
tene run -- npm start

Your code keeps reading process.env.STRIPE_KEY exactly as before. The change: the key never sits on disk in plain text, the AI agent can't index it, and an accidental git add can't leak it. For the full threat model, see Your .env is not a secret. AI can read it..

The sensible first stack for a vibe coder in 2026

If you're building your first real app, not a tutorial exercise, here's the path I'd defend:

• Frontend framework: Next.js. Huge ecosystem, best AI support.
• Database: Postgres on Supabase or Neon. Free tier, managed backups, scales far enough.
• File storage: Supabase Storage if you're already on Supabase. Cloudflare R2 if you want zero egress fees.
• Auth: Clerk or Auth.js (NextAuth). Don't roll your own.
• Deploy: Vercel for the frontend. The managed database lives on the Supabase or Neon side.
• Secret management: tene for local dev (keeps keys out of your AI agent's context) plus Vercel's environment-variable UI for production.
• Domain: Cloudflare. Cheap, fast DNS, free HTTPS on top.

That stack gets you to ten paying customers without a rebuild. Past that, you'll know what's breaking because you'll feel it.

What "production-ready" actually means

One last bit of framing. When people say an app is "production-ready," they usually mean it handles these five things without the founder being paged:

1. Availability: survives single-server failures
2. Observability: when something breaks, you can tell what
3. Security: secrets stay secret, users stay isolated from each other
4. Cost: the bill doesn't shock you at 3 a.m.
5. Recoverability: if the database melts, you can restore

Vibe coding shines at getting to the demo. The gap between demo and production is learning each of those five. The good news: every one has a platform-level answer in 2026. The better news: learn them once and they apply to every future project.

Summary — the shortest usable mental model

• Client / server: one asks, one answers. Always.
• Frontend / backend: seen and unseen halves of your app. Hostile browser, trusted server.
• Database / file storage: structured data vs big blobs. Different tools.
• HTTPS: encryption on the wire. Always. Free.
• CSR / SSR: where HTML gets built. Next.js does both.
• Infrastructure: the hardware you rent. Use a platform, not raw cloud, until you can't.
• Deployment: git push, wait, URL updates. Vercel, Fly, Railway, or raw cloud.
• Secrets: the one thing tutorials lie about. Keep them off disk and out of the AI agent's context from day one — that's what tene is for.

Terms used in this post

Localhost — A loopback address (127.0.0.1) that points back at your own machine. Anything on http://localhost:3000 is visible only to you.

DNS (Domain Name System) — The phone book of the internet. Turns a name like tene.sh into an IP address like 76.76.21.21.

HTTPS / TLS — HTTP wrapped in encryption. Stops anyone on the network path from reading or changing the bytes between browser and server.

API key — A secret string that proves your app is allowed to call a paid service. If it leaks, anyone can spend your money.

Environment variable — A value (often a secret) that the operating system hands to your app when it starts. Read with process.env.NAME in Node, or os.Getenv("NAME") in Go.

CDN (Content Delivery Network) — A worldwide cache for your static files. The user gets bytes from the server closest to them, so pages load faster.

SSR / CSR — Two ways to build HTML. SSR builds it on the server. CSR builds it in the browser with JavaScript. Hybrid mixes both.

Object storage — A separate service for big binary files (images, videos). You store the file there and keep only the URL in your database.

FAQ

I built an app with AI. Why can't my friends use it?

Your app is running on localhost — a loopback address that only resolves on your own machine. 'Shipping' means running that code on a server that's reachable from the public internet at a stable URL. Vercel, Fly.io, Railway, and AWS all solve this in different ways; the one-click options are fine to start.

Do I really need a backend? My app only has a few pages.

No, not always. If your pages are purely static content (marketing site, blog, portfolio), a frontend on Vercel is enough. You need a backend the moment you store data per user, call a paid API that must keep its key secret, or process payments. The moment you have an API key that must not leak, you also inherit the secret-management problem.

Can my AI agent see my .env file while coding?

Yes, by default. Claude Code, Cursor, Windsurf, and similar tools index project files to build context — .env at the project root is included unless explicitly excluded. This is the biggest security gap in the vibe-coder workflow, and the reason tene exists.

Related reading:

• Your .env is not a secret. AI can read it.
• Migrating from .env to an encrypted vault in 60 seconds
• Claude Code + API keys: the safe workflow