From Generated Code to a Live Site

ContentForger generates files. Getting them onto your machine is the first and simplest step, and there are exactly four exits in the current product.

Download ZIP. The download icon in the output viewer builds a ZIP in your browser from the parsed files, preserving every path, and saves it as contentforger-project.zip. This is the exit you will use for almost everything. If the output had no file markers (the model answered in prose), the same button saves a plain text file instead.

Copy all. The copy-all icon puts the entire output on your clipboard in its original marker format. This is the only exit that includes edits you made in the viewer's edit mode; the ZIP is built from the original stream. It is handy for pasting a single generation into an existing project.

Share link. The share icon creates a public page at /share/<id> with the prompt, model and a read-only file tree, plus its own copy and ZIP buttons. Anyone holding the link can download the code. There is no un-share control, so create one only when you mean it to be public.

Dashboard history. Every generation you have run is listed at /dashboard. Open one and you can copy its full output again. There is no ZIP button in the history view; copy the output, paste it into a file, and split it yourself, or re-share it to use the share page's ZIP.

For Agency accounts there is a fifth path: the REST API returns the code as a single string in a JSON response, in the same marker format. Writing that string out as files is your job. Plans, Limits and the Agency API Explained covers it.

The in-product Deploy guide (the rocket icon in the viewer) lists four setup steps with copy buttons. They are the same four you would do for any Next.js project. In order:

unzip contentforger-project.zip && cd contentforger-project
npm install
cp .env.example .env.local
npm run dev

Before the install, look at what you unzipped. The generator is instructed to include a package.json with test scripts, a README, a .env.example and the usual Next.js files. Check that package.json exists and is complete; a generation that hit its output cap can end with a truncated last file, and if that file is package.json nothing will install. The fix is cheap: go back to the conversation and ask for "the complete package.json only".

If the dev server starts and you see a page at the local address, you have a working baseline. Stop here and put the folder under version control before changing anything. ContentForger does not push to any repository for you, and the first commit is what lets you tell your edits from the generator's output later.

A note on package managers. The deploy guide uses npm because that is the lowest common denominator. If you prefer pnpm, delete any lockfile the generator emitted and run pnpm install instead; mixing the two is what causes most "peer dependency" surprises.

The generator is told to list every environment variable the app needs in .env.example. Step three above copies that file to .env.local, which Next.js reads and which should never be committed. Now you fill in the values.

What appears in the file depends on what you asked for, but the common shapes are predictable from the instructions the generator follows.

Three rules keep this painless. Fill every variable, even ones you think are unused; a blank one often fails at runtime rather than at start-up. Use test or sandbox credentials until the app is live. And never paste a key into a prompt or a follow-up; the generator does not need real credentials to write code, and anything in a prompt is saved to your history.

Two existing journal tutorials go deeper on the two most common providers: Supabase Auth in Your ContentForger App, and Add Stripe to Your ContentForger Output in 20 Minutes. Both are under /journal.

If your generation includes a supabase/schema.sql file, it is because the generator was told to create one whenever the app stores, lists or accepts data. The file should contain the tables, primary keys, timestamps, indexes and Row Level Security policies for the app.

Run it once against your Supabase project through the SQL editor in the Supabase dashboard. Read it before you run it. Two things to check in particular:

If the schema file is missing but the app clearly expects tables, ask a follow-up for "supabase/schema.sql for the tables used in lib/db.ts, with RLS policies". Then restart the dev server and exercise the pages that read and write data.

A dev server is forgiving. A production build is not, and both Cloudflare and Netlify will run one. Run it yourself first:

npm run build

The generator is instructed to produce strict TypeScript with no any types, and to include generateMetadata on every route and a dynamic sitemap. A clean build is the moment those instructions are confirmed for your specific output. If the build fails, read the first error only; later ones are usually consequences of it. Fix it locally or paste the error into a follow-up and ask for the corrected file.

The generator is also told to ship runnable tests: Vitest unit tests for the schemas and data layer, one Playwright end-to-end test, and test and test:e2e scripts in package.json. If they are present, run npm test. If the end-to-end test needs a running server, follow the script the generator wrote. Tests that were never run are decoration; tests that pass once on your machine are a baseline you can return to after every change.

Only when the build passes do you move on.

The Deploy guide in the viewer offers three targets with one command each. They are the full extent of what the product automates; everything else is your provider's own onboarding.

Those commands assume you are already logged in to the respective CLI and, for a first deploy, that you have created or will be prompted to create a project. The generated README is instructed to carry setup and deploy instructions for both Cloudflare Pages and Netlify; read the one you got, because it is specific to the app you generated.

Environment variables do not travel with your code. Every value you placed in .env.local must be entered again in the provider's dashboard or via its CLI before the first production build, otherwise the deployed app will start without its database or payment keys and fail in exactly the places the dev server worked.

For a fuller, screenshot-free walk through Cloudflare Pages specifically, the journal tutorial Deploy Your ContentForger App to Cloudflare Pages Free covers the account side. The broader question of which host suits which project is in Deploying ContentForger Output: Where and Why.

What ContentForger does not do at this step: it does not push to a Git host, it does not hold your provider credentials, and it does not run the deploy for you. The product ends at the files.

Open the deployed URL and check three things rather than admiring the home page: one page that reads from the database, one action that writes to it, and the sign-in flow if the app has one. Those are the three places a missing environment variable shows up.

Then decide how you will change the app from here, because there are two honest options and they do not mix well.

Keep iterating in ContentForger. Return to the conversation on /generate, ask for a change, download the new output and copy the changed files across. This is fast while the app is small. It gets awkward once you have hand-edited files, because a regeneration does not know about your edits and will overwrite them if you copy blindly. Version control is what makes this safe: commit before you copy, then review the diff.

Or treat the generated code as the starting point and develop it like any other Next.js project. The output is standard Next.js with no ContentForger runtime, so nothing ties you back to the generator. Most people who ship something real end up here within a week.

Either way, keep the original ZIP. It is the record of what the generator produced versus what you changed, and it is the easiest way to answer "did it ship like this, or did I break it?" six months from now.