Skip to main content

​
Custom domains for a project

You can put a project on your own subdomain (for example app.yourcompany.com) so customers open your brand, not only on a GenieForge subdomain. Apex domains (like yourcompany.com alone) are not supported yet; use a subdomain. When you add a domain, choose its purpose:
  • Portal: signed-in customer portal and public intake links
  • Project landing: public marketing site for that project. Public intake also opens here when the project has no Portal domain (or when a guest is already on this host)
  • App landing: public product marketing site for the app (not tied to one client project). Does not serve intake
Landing hosts are guest-facing celebration or product pages, not the signed-in portal. After you change a landing design in Building, Publish so visitors see the new look. Check an unpublished design first from Preview (surface Project landing or App landing, then Draft). Live binding props (names, dates, venue copy) can update without another publish. A project landing can also list published posts from a normal project table. Under App Settings → Appearance → Landing chrome, choose whether long landings show Back to top after visitors scroll down. The button sits on the page (lower right). Clicking it scrolls smoothly to the top (or jumps if the visitor prefers reduced motion). The page adds space at the bottom so the last lines stay readable. That setting is live (no Publish). It also applies in Preview on those landing surfaces. If you want guests to see Built and hosted by GenieForge at the bottom of the landing, ask Building chat to add that line. It is optional. It is not on by default, and it does not appear on the signed-in portal. After the landing design changes, Publish so visitors see it. The public landing host also serves a home-screen manifest (/manifest.webmanifest), a crawler allow file (/robots.txt), a /sitemap.xml of published guest URLs, and an llms.txt that lists the same pages. In Google Search Console, add the landing hostname and submit https://your-domain/sitemap.xml (not the GenieForge marketing sitemap). Builder Preview does not install as an app and does not need those files. Some AI crawlers are still blocked on the hostname. That is separate from GenieForge app access. A platform Slug (your-slug.genieforge.ai) is always a Portal-style host. Landing sites need their own landing-purpose custom domain. HIPAA-enabled apps cannot use Project landing or App landing domains.

​
Set it up

  1. Open Project Settings for the project.
  2. Under Public access & domains, confirm Public Project is on (new projects start with it on). Visitors cannot open a custom domain until this is on (Portal and Project landing). App landing hosts are app-scoped and do not require a project slug.
  3. Under Custom Domains, add a hostname and choose Portal, Project landing, or App landing. Every project also gets a platform Slug for a your-slug.genieforge.ai URL (neutral by default; you can rename it). Custom domains do not require that slug.
  4. At your DNS provider, create:
    • A CNAME from your hostname to the target shown in Project Settings (typically customers.genieforge.app)
    • A TXT record named _genieforge-verify.<your-hostname> with the token GenieForge shows
  5. Click Verify. Ownership is checked first, then SSL is provisioned. Status moves through pending verification, pending SSL, then active.
  6. If SSL is still pending, keep the CNAME in place and use Refresh until the status is active.
If you just bought the domain, your registrar can show the records while public DNS still cannot see the zone. Wait until a public lookup for _genieforge-verify.<your-hostname> works, then click Verify again. A “not visible in public DNS” error means the registry has not published nameservers yet, not that the Host values are wrong. In Build chat you can also ask: “Put this project on app.yourcompany.com as a Portal domain. Walk me through CNAME and TXT verify in Project Settings.”

​
Host field vs full DNS name

Project Settings shows the Host values to type at your registrar. Many registrars (Namecheap, GoDaddy, Cloudflare DNS) append your root domain automatically in the Host / Name field. Verify then looks up the full name in public DNS. If your zone is yourcompany.com and the custom domain is app.yourcompany.com: If you paste the full name into Host and the provider also appends the zone, the record ends up on the wrong name and Verify fails with “TXT record not found”. If a hostname points at the GenieForge CNAME target but is not an active public custom domain, visitors see a generic “This domain is not configured” page, not the GenieForge marketing site. If the domain is already active and a visitor instead sees “This site is temporarily unavailable”, that is a brief lookup issue. Refresh; it is not a DNS or Public Project problem.

​
Branding on your domain

Public project hosts (your custom domain and your your-slug.genieforge.ai subdomain) stay on your brand in the browser and when links are shared:
  • Tab icon uses your app or project favicon (or logo), not the GenieForge favicon. After you replace that file, refresh the public page to load the new icon.
  • Link previews use your app name, description, and social image when you have set them under App Settings (or project branding overrides)
  • Google Search can show that same app name as the site name above results for your landing, instead of only the domain
  • Cookie and marketing chrome from GenieForge do not appear on these hosts
Set the app description and branding assets before you share the public URL so previews look right the first time.

​
Public intake on your domain

Published Public intake links and personalized invite links use your active Portal custom domain when one is set. If the project has a Project landing domain and no Portal domain, intake links and landing visit buttons use that landing hostname so guests stay on your brand. Optionally set a Public path alias on the form (for example rsvp) so intake URLs look like https://www.yourcompany.com/rsvp/… instead of the default GenieForge path. App landing domains do not serve intake. Login and the signed-in portal still use the Portal domain or your public project subdomain. If the project has more than one active Portal custom domain, GenieForge picks one preferred host for newly minted links. Every active Portal domain still serves the form if someone opens that host. Remint or republish after you change domains so printed QR codes and stored invite links pick up the new host.