You built an app with Claude Code. Here's how to put it on the internet.

You know the screen. A terminal, something running at localhost:3000, and the slow realization that "it works" and "my mom can open it on her phone" are two very different problems. Building software with an agent has got maybe ten times easier over the last two years, and getting the result onto the internet has stayed about as annoying as it always was.

I'm going to write down both ways out. The first is the standard path, and I've tried to be straight about it because it works and most people reading this will take it. The second is the one where the deployment problem doesn't come up, because the agent never produced a codebase that needed deploying. That second one is the product I make, so I'm not neutral about it.

#The standard path, in six steps

Say Claude Code built you a Next.js, Vite or Express app. Here's the whole route from your laptop to a URL. Three accounts, and about an hour the first time if nothing goes wrong, which it will.

1. Put the code in a repository. Make a GitHub account if you don't have one, create an empty repo, push. Claude Code will run the git commands for you if you ask. Check that .env is in .gitignore before it does, because it's a lot harder to un-push a key than to not push it.
2. Pick a host. Vercel or Netlify for a front-end framework. Render or Railway if there's a server and a database. Connect the host to your GitHub account, select the repo, and the host reads the framework and guesses the build command. It usually guesses right.
3. Copy your environment variables in. Every API key and database URL sitting in .env needs typing into the host's settings before the first build. Miss one and the build succeeds and then the app falls over at runtime, and it takes a while to work out why.
4. Build, then read the log. The first build fails more often than it passes. A package that works locally but never made it into package.json, a Node version mismatch, a file path that only works on a Mac. Paste the log back into Claude Code and go again.
5. Buy a domain and point it. A separate registrar, a DNS record the host tells you to add, and a wait while it propagates.
6. Do it again for every change. Commit, push, build, deploy. The host automates most of that, which is genuinely good. What it can't do is tell you what a change is going to break, and every one of those steps is somewhere a day-two problem can sit unnoticed.

Two things before you start. If Claude Code reached for a hosted database, check its security rules before you go public. A scan earlier this year of 1,072 AI-built apps found 172 that let anyone delete data without signing in. And add error tracking on day one. You will not otherwise find out when something fails, and your users mostly won't tell you either.

So that's the standard path, and it's fine. I've done it more times than I'd like. Six steps and three accounts to get one page online, though, and every one of those steps is there because the thing you're shipping is a codebase.

#The other way: don't deploy code

Tessryx takes a different position on what the agent should produce in the first place. Instead of writing code that then needs a host, the agent writes definitions into a system that's already running. A schema for the data, then the data, then a workflow that renders the page or answers the API call, and an endpoint that binds the workflow to a URL. Nothing lands in a folder, so there's nothing to push, nothing to build, and no host waiting for an environment file. The running system is where the definitions already live.

Here's what that looks like on a site I actually built this way.

#1. Create an account and connect the agent

Sign up (free, no card), confirm your email, and open the Getting started card on the dashboard. For Claude there's a one-click Add to Claude button that opens Claude's connector dialog with the Tessryx address already filled in, and for ChatGPT a Try in ChatGPT button that opens Tessryx's listing in the plugin directory. Approve it, pick a workspace, done. For Claude Code, Cursor or any other MCP client, the same card shows the server URL to paste into that client's connector settings. The full flow, including what the agent can and can't do once connected, is in Connect your agent.

That's the whole setup. The agent now has the same build access you have in the web app, and none of your secrets.

#2. Describe the outcome

This is the exact prompt, typos included, that produced birthday.nickpage.tech:

alright, i have a domain in tessryx birthday.nickpage.tech. i need an app in tessryx for it that will be a birthday invite site with magic links for the people i invite. and then an admin area that i have access to that allows me to manage those magic link invites.

lets keep it simple but nice looking for now, but then later we'll work on the fancy styling for it

One prompt, no follow-ups. The agent built the site, tested it, found a bug in its own work and fixed it before handing over. The whole conversation is shared here if you want to see it work, including the bit where it catches itself.

#3. What the agent actually made

Sixteen pieces, all definitions:

• two schemas (event details, the invite list) that validate the data and generate the editing forms
• two datafiles holding the event copy and the guest list
• six workflows: one per page, one for the RSVP submit, one for the admin API, and a shared theme
• five endpoints binding those workflows to URLs, including the magic-link route i/:token and the admin behind sign-in
• one custom domain pointing at the home endpoint

The endpoint for the public home page is the whole "deployment". This is it, verbatim:

{
  "workflow": "birthday/home-render@published",
  "methods": ["GET"],
  "input_mode": "none",
  "cache": {
    "s_maxage_seconds": 300,
    "stale_while_revalidate_seconds": 3600
  }
}

A URL bound to a workflow, with a five-minute edge cache. There's no build output because there's nothing to build. When the agent saves that, the platform validates it against the endpoint schema on the spot, and if it had referenced a workflow that didn't exist, the save would have said so.

#4. Preview, then publish on purpose

Nothing an agent builds is live until someone publishes it. Drafts are free, private, and can be previewed exactly as they'd serve. The agent can also preview a page as a specific signed-in viewer, so it can check the admin area as the admin and then as a stranger before anyone else can reach it.

Publishing is one deliberate act per piece, and it's refused if anything the piece depends on doesn't resolve. This is the step that replaces "build and read the log". It fails before any visitor sees anything. Details in Publishing.

#5. The domain

On the free plan the site is live straight away at a tessryx.app subdomain, with a small "Served by Tessryx" badge and a noindex tag. So it's a real URL you can send people, and not one search engines will list. That's the trade for free hosting.

On a paid plan you add your own hostname from the dashboard and get two DNS records to publish at your registrar. One is a TXT record that proves you control the domain, and the other is a CNAME that routes the traffic and gets the certificate issued. This is the one step with a human in the middle, because nobody can add records to your DNS for you, and it's the step people get stuck on. The status walks from pending to verified to certificate pending to active, usually inside a few minutes once the records are right. For the birthday site the CNAME points birthday.nickpage.tech at Tessryx and the domain's root is the home endpoint. That's the entire routing configuration. The walkthrough, and the apex-versus-subdomain gotcha that catches everyone once, is in Custom domains.

#6. Changing it later

There isn't really a step six. Editing the guest list is a form in the site's own admin. Editing the page is the agent changing a definition, previewing it, and publishing a new version, with the old one serving until that moment and available to roll back to afterwards. And before a change goes out, the platform can report what it would break, since it knows every reference between those sixteen pieces. That's a longer story and I told it in The invisibility problem.

#"But I already built it with Claude Code"

Then it depends what you built.

Tessryx doesn't import a Next.js repository. The agent rebuilds the app from its spec, as definitions. For the things most people are shipping from localhost:3000 (a marketing site, a portal with sign-in, a form and a table, a page over somebody's API, a scheduled job) that's usually quicker than the first deployment would have been. Point the agent at your existing code and ask it to build the same thing on Tessryx. It can read the code, and it remembers what it was trying to do.

If you built something with a heavy custom front end, a real-time game loop, or a native mobile app, deploy the code. The six steps above are the right tool for that. I'm not trying to build a replacement for them.

#What it costs to leave it running

Building, drafting, editing and saving are free on every plan. You're metered on executions: a page render, an API call, a scheduled run, or the agent calling something over MCP, however it was triggered. A cached page is served from the edge without running anything, so a well-cached site uses a small slice of even the free allowance. The people who use the site are unlimited on every plan, including anyone who signs in to an editor the agent builds into it. Workspace seats are for the people who build and edit inside the Tessryx app itself. The full table is in Plans and limits.

#Start here

1. Create a free account and confirm your email.
2. Connect Claude, Claude Code, ChatGPT or Cursor from the Getting started card.
3. Describe the outcome. Be as scruffy as my prompt above. It was enough.
4. Preview, publish, send the link.

The app on your laptop is most of the way there already. Give it somewhere to live that you'll still understand in six months. Mine is at birthday.nickpage.tech if you want to see what that looks like.