Your agent wrote an app. Here’s how to put it online.

Every Claude Code tutorial ends the same way: something wonderful running on localhost:3000, in a browser tab only you can see.

The video taught you how to describe an app and watch an agent build it. It didn’t teach you the part that comes next, because the part that comes next is boring to record: accounts, dashboards, build settings, DNS. So thousands of finished apps die on laptops, one closed terminal at a time.

This post is the missing last chapter. First what “online” actually means, then your realistic options, then the shortcut.

What localhost gives you for free

Your machine quietly provides five things the internet doesn’t:

• A running server. The app dies when you close the lid. Online, something has to keep it alive — and restart it when it crashes.
• An address. localhost only means something to you. Other people need a URL.
• HTTPS. Browsers mark plain HTTP as insecure, and they’re right to. You need a certificate, renewed forever.
• A place for data. That SQLite file next to your code needs to survive deploys and restarts.
• Privacy. On your laptop, nobody else can open the app. On the internet, everybody can — unless you build a login.

None of this is hard for someone who deploys weekly. All of it is friction for someone whose first app got written for them yesterday.

The usual paths, honestly

Static hosts — Vercel, Netlify, GitHub Pages. Excellent for frontends, and free to start. You create the account, install their CLI, configure the build, and host any backend somewhere else. Read the free-tier terms before you depend on them: Vercel’s Hobby plan, for instance, excludes commercial use.

App platforms — Railway, Render, Fly.io. Real servers that run real backends. Built for developers, priced mostly as a monthly fee per service, and the setup — databases, environment variables, domains — is yours to do in their dashboard.

A VPS. Five dollars a month for full control. Also: congratulations on your new job as a system administrator.

All three paths share one assumption: you do the deploying. Which is odd, because you didn’t do the writing. The agent knows the entry point, the environment variables, the build step — it wrote them. Asking it to produce a deployment checklist for you to execute by hand gets the division of labor exactly backwards.

Let the agent do the last step too

This is the premise Alora is built on. You connect your agent once:

npx alora-cli connect   # shows a code — paste it at alora.build/activate

From then on, “put this online” is a sentence, not a project. Your agent runs:

alora create ideas
alora deploy
→ https://ideas.alora.page   ✓ live, with TLS

And the five problems from above are already handled:

• The app runs in its own VM and sleeps when idle, waking on the next visit — you don’t pay for the hours nobody’s looking.
• It gets a real URL at yourproject.alora.page, HTTPS included. A custom domain connects for free — or your agent can buy one, with your approval by email.
• Anything written to the data directory survives deploys and restarts.
• Every app is born private: visitors hit a login page, and you invite people by email with a role. Your agent never writes auth code, and “share it with my team” is one command.

What it costs

New accounts get $0.50 of credit free, which covers your first deploys entirely. After that it’s pay-per-use from a prepaid balance: $0.01 per active hour, $0 while the app sleeps, $0.40 per GB of storage a month. A typical side project lands under a dollar a month, and your balance is a hard ceiling — an agent can’t spend money you didn’t load. Full numbers on the pricing page.

The tutorial’s last chapter was never supposed to be homework. Ask your agent to ship it.