Deploy your site & connect a domain

Steeren runs the marketing layer (CMS, leads, CRM, newsletters, analytics) behind your website. The website itself can live wherever you want. This article covers the two ends of getting it live: putting your site online and connecting your own domain - plus the snags you'll actually hit while doing it, and how to clear them.

There are two things Steeren can put on a domain:

• Your blog - the pages that render your published posts. This is already live the moment you publish, on your platform address <your-workspace>.nukipa.com.
• Your site - your own marketing site (for example, a Next.js project). This is what most of this article is about.

So your blog is online as soon as you publish a post. You only touch it again if you want it on a custom domain too. Everything below is mainly about getting your site live and onto your own domain.

[!NOTE] Throughout this article, nukipa.com is the blog address and nukipa.io is the site address. Those are the production addresses - if you're on a different environment, your platform addresses will differ, but everything works the same way.

How your site goes live

There are two ways your site gets online.

1. You host it yourself. If you keep the site in your own repo and deploy it on your own host (Vercel, Netlify, wherever), Steeren isn't in the deploy path at all. Your site just needs to reach Steeren at runtime to pull in your content - see how your domain finds your content below. Skip the next section.

2. Steeren deploys it for you. If you connect a GitHub repo through Steeren, it provisions and builds the site for you. Connecting the repo is the trigger - once it's connected, the first build kicks off automatically.

A few things to know about the managed deploy:

• The first deploy runs in the background and takes a little while. When it's done, your site is live on its platform address, <your-workspace>.sites.nukipa.io.
• Re-running a deploy is safe - it won't break anything that's already live.
• If you change which repo is connected, the next deploy rebuilds from the new repo.
• If a deploy doesn't kick off on its own, you can re-fire it from the redeploy button in your dashboard.

[!TIP] If you connect a repo but the first build never starts, the most common cause is that your host can't see the repo yet. On Vercel, that means installing Vercel's GitHub App on the organization that owns the repo and granting it access to that specific repo, then re-running the deploy. A "did not start a deployment" message usually means the same thing - or that the branch has no commits yet.

How your domain finds your content

Every visit to your blog or your site carries the address it was requested on (the host). Steeren uses that host to figure out which workspace's content to serve. There are two ways a host maps to your workspace:

1. Your custom domain - once it's verified, visits to that exact domain serve your content.
2. Your platform address - <your-workspace>.nukipa.com for the blog, <your-workspace>.sites.nukipa.io for the site.

For most people this is invisible: you point your domain at Steeren, it verifies, and the right content shows up. The rest of this section is only relevant if you're hosting the site yourself and wiring it up by hand.

If you host the site yourself

Your site needs to tell Steeren which host the visitor came in on, so the right workspace resolves. The starter does this for you in src/lib/nukipa.ts: it sends the real visitor host first, and only falls back to a host you've pinned:

getHost: () => h.get('x-forwarded-host')
             || h.get('host')
             || TENANT_HOST   // NUKIPA_TENANT_HOST - fallback only
             || ''

Two environment variables matter here:

• NUKIPA_GATEWAY_URL - where your site reaches Steeren. Always set this.
• NUKIPA_TENANT_HOST - a fallback host for situations that have no incoming request (build time, for example). Set this to a host Steeren can resolve.

In local development, localhost doesn't map to any workspace, so set NUKIPA_TENANT_HOST to a real, resolvable host (your platform address works) to see your content while developing.

[!WARNING] Keep NUKIPA_TENANT_HOST as a fallback only - never let it override the real request host. If your site always sends the fallback instead of the actual visitor host, then when Google crawls your custom domain, your site asks Steeren about the platform subdomain instead. That subdomain carries no Search Console verification token, so the verification tag renders empty and Google reports "verification token could not be found on your site." If you write your own client, resolve the real request host (x-forwarded-host, then host) first, and forward it to Steeren.

[!NOTE] Platform subdomains (<your-workspace>....) and custom domains behave differently in one important way: a custom domain is the public, indexable home for your content; a platform subdomain is the working address and is kept out of search results. So Search Console verification only matters on your custom domain.

Connecting a custom domain

Connecting your own domain to your site is a few steps:

1. Add the domain in your Settings -> Site panel.
2. Steeren gives you the DNS records to create.
3. You add those records at your DNS provider (the company you bought the domain from, or wherever you manage DNS).
4. Steeren checks for the records and, once they resolve and the certificate issues, marks the domain verified. The panel updates as it goes - you can re-check at any time.

The records you need depend on whether you're connecting an apex domain or a subdomain:

[!NOTE] Sometimes you'll be shown a slightly different (region-specific) CNAME, or an extra record to prove you own the domain. If so, just create the exact records the panel shows you - those override the generic ones above, and the domain verifies once they're in place.

A domain is live only when it's fully verified - both that you own it and that DNS is pointing at us. Until then the panel shows it as still verifying. Once it's verified, that's your signal the domain is serving your site.

[!TIP] www. vs. the bare domain. When you connect a domain, the www. part is dropped - connecting www.example.com stores example.com. Your content is served on the bare domain, and a visitor hitting www.example.com won't resolve unless you redirect it. If you want your site on www., set up a redirect at your host from www. to the bare domain (or the other way around).

[!NOTE] Each domain belongs to exactly one workspace and one surface. Re-adding the same domain to the same site is harmless. Trying to add a domain that's already in use elsewhere - on another workspace, or already serving as a blog domain - will be rejected. The Settings -> Site panel only manages site domains; connecting your blog to a custom domain is a separate flow.

[!WARNING] "No project yet" when adding a domain. If you've just connected a repo through Steeren, the project that hosts your site doesn't exist until the first deploy finishes - and that runs in the background. So you can have a repo connected and still be told there's no project to attach the domain to. The fix is to wait for the first deploy to complete (or re-fire it from the dashboard), then add the domain.

Keeping your site fresh when you publish

When your domain first verifies, Steeren can ping your site to refresh its cache the instant you publish or unpublish a post - so changes appear immediately rather than on the site's natural refresh cycle.

For that instant refresh to work on a self-hosted site, your site needs a shared secret set in its NUKIPA_REVALIDATE_SECRET environment variable, matching the one Steeren generated for the domain. (The starter ships the receiving handler already; you set the env var yourself after the first deploy.) If the secret is missing or doesn't match, your republished posts still go live - just on the site's normal refresh window (around a minute) instead of instantly.

Google Search Console verification on a custom domain

Steeren proves ownership of your custom domain to Google using the HTML meta-tag method, automatically, so your search analytics flow in. A couple of things to know:

• It only runs after your domain is verified. Steeren won't attempt Search Console verification until your domain is DNS-verified and serving your site. So it's normal to see a domain that's live but not yet Search Console-verified for a short while - Google needs to crawl your site and find the tag.
• It can take a few crawls. If Google hasn't found the tag yet, Steeren keeps retrying on its own. You don't need to do anything; it resolves once Google's crawler picks up the freshly-rendered tag.

If Search Console verification stays stuck, the usual cause is that Google can't actually reach your site to read the tag - see the troubleshooting below.

Common snags and how to fix them

[!WARNING] Blank page or no content. This almost always means the host isn't resolving to your workspace. Check, in order:

1. Is the address a real workspace host? localhost resolves to nothing in local dev - pin a resolvable host with NUKIPA_TENANT_HOST.
2. For a custom domain, is it actually verified yet, and are you hitting the exact domain that's stored? A domain that's still verifying won't serve content, and the www. variant of a bare-domain row won't resolve unless you've set up a redirect.
3. For a platform address, are you using the correct <your-workspace>.... host, with a single workspace label (no extra dots)?

[!WARNING] A login or password wall instead of your site. Some hosts (for example, Vercel's Deployment Protection) put an authentication wall in front of your deployment that intercepts every request - including Google's crawler. Steeren doesn't touch this setting, so if it's on, turn it off for your production domain in your host's settings (on Vercel: Project -> Settings -> Deployment Protection). A site behind that wall will never verify in Search Console and won't be publicly reachable.

[!WARNING] Search Console verification never finishes, and the verification tag is empty on your custom domain. On a self-hosted site, this usually means your site is sending the wrong host to Steeren - the fallback NUKIPA_TENANT_HOST is winning over the real visitor host, so reads are scoped to your platform subdomain (which has no verification token). Fix: resolve the real x-forwarded-host / host first and only fall back to NUKIPA_TENANT_HOST.

A domain that was working now shows as failed. This usually means the domain was removed from the underlying project (often manually, at your host). Re-add it through the Settings -> Site panel.

FAQ

Do I have to let Steeren deploy my site? No. If you host the site yourself, Steeren never deploys anything. Your site just needs NUKIPA_GATEWAY_URL set and needs to send the real visitor host when it reads from Steeren. The managed deploy is only for the connect-a-GitHub-repo path.

My blog is on <your-workspace>.nukipa.com. How do I put it on my own domain? That's a separate flow from the site domains in this article. The Settings -> Site panel only manages your site's domains; connecting your blog to a custom domain is handled elsewhere.

Why is my site on <your-workspace>.sites.nukipa.io and not <your-workspace>.nukipa.io? That's just the platform address for sites, kept separate from blog addresses so they don't clash. It's the working URL - your custom domain is what visitors actually use once it's verified.

I connected a repo but I'm told there's no project when I try to add a domain - why? The project that hosts your site doesn't exist until the first deploy finishes, and that runs in the background. Wait for the deploy to complete (or re-fire it from the dashboard), then add the domain.

I republished a post but my site still shows the old version. Instant updates rely on the refresh secret being wired up: your site's NUKIPA_REVALIDATE_SECRET must match the one Steeren generated for your verified domain, which you set after the first deploy. Without it, the change still appears - just on the site's normal refresh window (about a minute).

Is Search Console verification the same as my domain being "live"? No. A verified domain means it's serving your site. Search Console verification means Google has accepted ownership for search analytics. Steeren only attempts Search Console verification on domains that are already live, so it's normal to be live first and Search Console-verified a little later.