Hosting a Claude Code Frontend for Knack

What you'll learn

A Claude Code frontend needs its own web address before anyone can sign in to it, because Knack only accepts https sign-in addresses. Getting there takes two steps: saving your work to GitHub, then deploying it to a host. This article covers why each one matters and how to register the resulting address with Knack.

Why your frontend needs a web address before anyone can sign in

Knack handles sign-in on its own hosted page. Your app sends the user to Knack, the user enters their credentials there, and Knack sends them back to your app afterwards.

That return trip is the reason hosting matters. Knack will only return a user to an address you registered in advance, and registered addresses must use https. A plain http://localhost address can never be registered.

So until your app has a real https address, nobody can log in to it. Including you.

What you need

• A GitHub account, which stores your code and its history
• A hosting account that publishes from GitHub, such as Cloudflare
• Builder access to your Knack app, for registering the address

Why GitHub matters more here than you might expect

Claude Code builds your app on your own computer. Until you save it somewhere else, your app exists in one folder, on one machine, with no copy anywhere.

That is different from what you may be used to. Platforms that build and host your app keep your code on their servers automatically, so there is nothing to think about. This path gives you control over where your app lives, and the cost of that control is that backing it up is now your job.

GitHub does three things for you, and only one of them is about deployment.

It keeps a copy that is not your laptop. If your machine is lost, stolen, or wiped, your app survives.

It keeps every version. Every time you save your work, GitHub records what changed. If a round of changes breaks something that used to work, you can go back to the version that worked. This matters more than it sounds when you are building by describing changes in conversation, because it is easy to accept several changes in a row and then realize the app was better three steps ago.

It is how your app gets published. Your hosting service watches your GitHub repository and republishes your app whenever it changes. After the first setup, saving your work is all it takes to update the live site.

Saving your project to GitHub

Ask Claude Code to save your project to GitHub. It handles the setup.

What you need to confirm afterwards is that your files actually appear in the repository when you open it in your browser. A reported success is not the same as files arriving.

Do this while the project is small. A connection problem takes minutes to fix with a handful of files and much longer with hundreds.

After that, save your work regularly rather than once at the end. Ask Claude Code to save to GitHub whenever you finish something that works, and always before asking for a large change. Those saved points are what you fall back to.

Deploying your frontend

Connect your hosting service to the GitHub repository and deploy. The details vary by host, and your host's own documentation is the right reference for the specifics.

Deployed is not the same as reachable. Some hosts publish your app but leave its public web address switched off. If the deploy reports success and the address returns nothing, look for a domains or settings screen where the address can be enabled.

Your host needs a configuration file, and Claude Code writes it

Most hosts read a small configuration file in your project that tells them what to publish. Claude Code creates that file for you, but only if it knows which host you are using. You will not be asked for it.

The file does two jobs, and both matter to whether sign-in works.

It tells your host which folder holds the finished app. Without this, the deploy fails and the log complains about a missing configuration or entry point. Nothing gets published, so the failure is at least obvious.

It also tells your host to serve your app for any address it does not recognize. This one fails quietly. Your app is a single file that draws each screen as you move around it, so the address Knack returns users to after sign-in is not a file sitting on your host. Without this setting, your home page works, and then sign-in returns a "not found" error that looks like an authentication problem and is not.

How to get it right the first time. Add one sentence when you first describe your app:

I'll be deploying this to Cloudflare, so include whatever config that needs.

Replace Cloudflare with whichever host you are using. You are telling Claude Code where the app is going, not how to configure it. That is enough for it to set the file up correctly before you ever deploy.

Host configuration formats change, so your host's own documentation is the right reference for exact syntax. In practice you should not need it, because this is a question to hand to Claude Code rather than one to answer yourself.

Registering your web address with Knack

Once your app has a live address, register it with Knack. Ask Claude Code to do it, giving it the address your host assigned.

Knack registers a sign-in return address, which is your app's address followed by the path your app uses for the return trip. Claude Code knows which path it built.

What happens when your web address changes

Changing your app's address means registering the new one. Until you do, sign-in fails for everyone.

Re-registering also ends active sessions, so anyone signed in at the time is signed out.

This is worth a decision rather than a discovery. If you plan to use a custom domain, set it up before you invite real users, so the address people first sign in on is the address you intend to keep.

Testing sign-in on the live address

Local testing does not prove sign-in works. The sign-in flow can only run on a registered https address, so it has to be tested on the live one.

Sign in as a real user of each role and confirm three things:

1. Knack's sign-in page appears when you start the flow
2. You return to your app afterwards and stay signed in
3. You see the records that role should see, and no others

The third check matters most. An app that signs people in correctly can still show them the wrong records. See Checking That Your Access Rules Actually Work for how to test that properly.

Common mistakes

Testing sign-in on a preview address. Some hosts create a separate address for each branch or preview build. Those addresses are not registered with Knack, so sign-in fails on them. Test on your production address.

Registering the address before the host assigns it. Host addresses are not always predictable. Deploy first, read the address your host gives you, then register that.

Assuming a successful deploy means a working app. Confirm the address loads in a browser before you register anything.

Leaving GitHub until the end. Saving your work once, after everything is built, gives you a backup but no history to fall back on. Save as you go.

Not naming your host when you describe the app. Claude Code cannot write deployment configuration for a host it has not been told about. One sentence at the start prevents a failed deploy later.

Next steps

• Connecting Claude Code to Knack covers the Knack MCP Server connection this builds on.
• Troubleshooting Claude Code and Knack covers the errors that show up during deployment and sign-in.
• How Authentication Works with a Custom Knack Frontend explains the sign-in handoff in more detail.