Take your own website live

Some organisers have a website of their own, built as code by a developer or an agency, rather than the one Grofomo generates. This is how you get that site onto the internet at your own domain, with Grofomo still handling sign-ups, tickets and feedback behind it.

If you are using the site Grofomo builds from your event data, you want Build your event website instead. That one publishes itself and needs none of this.

The whole thing takes an afternoon, and nothing your visitors can see changes until the very last step. Up to that point you are working on a private copy.

Before you start

The site's code has to be on GitHub, on the main branch. If somebody else built it, ask them to confirm everything is committed and pushed. The host builds from the repository, so anything still sitting on their laptop will not appear on the live site.

Set up the hosting

Cloudflare Pages hosts the site for nothing and rebuilds it automatically whenever the code changes.

Go to dash.cloudflare.com and log in.
In the left menu click Workers & Pages, then the blue Create application button at the top right.
At the bottom of the "Make something new" card there is a line of small grey text: "Need to use the legacy Pages workflow?" Click the Continue to Pages link at the end of it. It is easy to miss, and none of the big buttons above it are the one you want.
The next screen is headed Get started. Click the Get started button on the "Import an existing Git repository" row.
Stay on the GitHub tab and approve GitHub access if you are asked. Check the GitHub account shown in the dropdown is the one the site was built under, and use Add account if it is not there.
Use the Search repositories box to find the site rather than paging through the list, then click it. If it never appears, the Cloudflare Pages app on GitHub has not been given access to it, and the Cloudflare Pages link under the list is where you grant that.
Click Begin setup.
The Project name at the top is filled in from the repository name, and you can change it to anything you like. It is only a label, but your test address is built from it, so summer-party gives you summer-party.pages.dev. Get it right now: Cloudflare will not let you rename a project afterwards, and the only way to change the address is to delete the whole project and set it up again from step 2.
Leave the production branch as main.
Set the Framework preset to whatever the site was built with. If you do not know, ask the developer. It is one word and they will answer instantly. Picking the right preset fills in the two boxes below it for you.
Check the Build command now reads npm run build and the Build output directory reads dist. That is what Astro and most other presets set, and it is what a developer-built site normally needs. If the preset filled in something different, leave it alone: it knows the tool better than you do. If the developer gave you a build command of their own, use theirs over any of this. On a site that reads Grofomo when it builds, that command is what fetches your line-up, and replacing it with the standard one ships whatever content was last saved into the repository.
If the site is plain HTML, CSS and JavaScript with nothing to build, set the preset to None, leave the build command empty, and set the output directory to the folder holding your index.html, which is usually just /. Check with the developer before emptying it, though: a plain HTML site can still have a build command whose whole job is to fetch your line-up from Grofomo, and emptying that one leaves the site frozen on old content while every deploy still reports Success.
Click Save and Deploy, and wait for the log to finish with Success.

You will be given an address ending in .pages.dev. That is your test site: a real, working copy of your website that nobody else knows the address of. Keep it somewhere handy, you will need it twice more.

If the build fails

Cloudflare shows a red Build failed with the log underneath it. The real error is in the last few lines, above the "Failed:" summary. Two failures account for most of them.

npm error code ENOENT naming package.json. Cloudflare ran npm run build on something that has no build step, or the site is not where it looked. Open the repository on GitHub and look at the top-level list of files. If there is no package.json there and no folder that looks like the site, there is nothing to build: set the preset to None, empty the build command, and set the output directory to /. If the package.json is inside a folder such as site or astro-site, put that folder's name in Root directory and leave the rest alone.

command not found, or No such file or directory naming something that is not a file of yours. The build wants a tool that is not installed on Cloudflare's machines, usually because it only exists on the developer's own computer. You cannot fix this from the dashboard. Send them the log and ask them to make the build work on Linux.

To change any of the settings afterwards, go to Settings, then Build. Settings only reach the site on its next build, so then open Deployments, click the ... menu on the newest deployment and choose Retry deployment.

Add the two settings

Two settings connect the site to Grofomo and keep the test address private until you are ready to launch.

In the Pages project click Settings, scroll down to Variables and secrets, and click Add. Add these two:

PUBLIC_API_BASE, set to https://api.grofomo.com. This is what lets your site read your line-up and take sign-ups.
STAGING_PASSWORD, set to any password you choose. This locks the test address so nobody stumbles across the site early, and it switches itself off automatically once your real domain is attached.

Three things catch people out here, and all of them are easier to get right than to fix later.

Add each setting twice, once for Production and once for Preview. The Choose Environment dropdown at the top of the Settings page decides which of the two you are editing, and Cloudflare keeps them as separate copies. Filling in only Production is the most common mistake of the whole process. The bare .pages.dev address is the Production one, so a password saved only to Preview leaves your test site open to anyone who guesses the address.

These only work if your site was built to use them. They are instructions to your site's own code, not switches Cloudflare acts on. If the developer built the site to Grofomo's spec it reads both. If they baked your line-up in at build time instead, or built you a plain page with no code behind it, the settings sit there doing nothing and your test address has no password on it. Ask the developer which it is rather than assuming the password took.

Do not put quote marks around the values. In the Cloudflare dashboard the quote marks become part of the value itself, and the setting silently does not work.

Then go to the Deployments tab, open the ⋯ menu on the newest deployment and click Retry deployment. Settings only reach the site on its next build, so without this they sit there doing nothing. When it finishes, opening your test address should ask you for a username and password. Any username will do.

Let the site talk to Grofomo

Sign-up and feedback forms only accept submissions from addresses on your event's allowed list. Until you add your site, its forms will look like they work and then quietly fail to save anybody.

Open Connect your site under Create, and add all three addresses now so there is nothing to remember at the launch moment:

your .pages.dev test address
your real domain
the www. version of your real domain

Write them as full addresses starting with https://, not bare domain names. A bare domain is the usual reason a developer's page gets refused.

Check the hidden site properly

This is your one chance to look at everything before anybody else can. Open the test address, log in with the password you chose, and work through it honestly:

Check the home page and every other page loads.
Check images, video and animations behave, on your phone as well as your computer.
Put a real email address into the sign-up form. You should see the success message, and that person should appear in your Grofomo contacts.
Click any links you have shared before, such as ticket links or FAQ links, and check they still land somewhere sensible.

Fixing anything now costs nothing. Fixing it after the switch means doing it in public.

Make it rebuild when you publish

Set this up before launch, not after. Without it, publishing a line-up change or a news article does nothing to your site until somebody rebuilds it by hand.

In the Pages project click Settings and find Deploy hooks, which sits with the other build settings. Add one on main and copy the URL it gives you.
In Grofomo open Settings, then Webhooks. Add a webhook on Website content changed, paste that URL in, and scope it to this event.

Publishing a line-up, an article or an FAQ now rebuilds the site on its own. Changes inside one minute arrive as a single rebuild, so a bulk edit triggers one build rather than fifty.

One thing to check with whoever built the site. A rebuild only replays whatever is in the repository. If the build reads Grofomo each time it runs, this works. If it reads a copy of your content saved in the repository instead, every rebuild puts the same old content back, and nothing you publish will ever appear however many times it rebuilds. The deploy will say Success each time, which is what makes it hard to spot. Ask them to confirm the build fetches from Grofomo. It is usually a one-line change to the build command, and it is the difference between this working and only looking like it works.

Switch your domain across

This is the launch. The moment you activate the domain, visitors see the new site instead of the old one.

In the Pages project click the Custom domains tab.
Click Set up a custom domain, type your domain, and click Continue.
Cloudflare shows you the change it is about to make: the old record pointing at your previous host, and the new one pointing at your Pages site. Click Activate domain.
Do the same again for the www. version.

Ignore the notice about it taking up to 48 hours. In practice it is usually minutes. The sign that it worked is the status moving from Verifying to Active. Open your domain in a private browsing window to see what a visitor sees.

Your old site is still sitting there untouched. If anything looks badly wrong, the domain can be pointed back at it in minutes, which is your safety net.

After launch

Three small jobs, and none of them are urgent today.

Leave the old site alone for a week. It costs one more month at worst, and it is the thing that gets you out of trouble if a problem surfaces on day three.

Then cancel the old plan. In Webflow that is Site settings, then Plans. Keep the project itself as an archive, it costs nothing without a plan. Cancelling before you are confident is the one genuinely hard-to-undo step in this whole process, which is why it comes last.

Tell Google about the new site. Submit your sitemap, at your domain followed by /sitemap-index.xml, in Google Search Console. Your pages will be found either way, this just makes it quicker.