Hosting & Custom Domains

Publish static or fullstack apps, connect a custom domain, configure DNS, and verify automatic TLS

Gencow can host a frontend by itself or serve it with a Gencow backend. Every cloud app receives a managed *.gencow.app URL. Startup and Enterprise plans can also connect a domain that you own.

Choose a Hosting Mode

Build the frontend before publishing it. For new apps, use Vite + React unless you specifically need a server-rendered framework.

Add --prod only when the user or operator explicitly requested the separate production app. A generic request to deploy still means the default development target:

bun run build
gencow deploy --static --prod dist/

Production deploys and custom domains are available on Startup and Enterprise plans. See Cloud Plan Limits for the complete matrix.

Before Connecting a Domain

Confirm all of the following:

1. The intended dev or production app has a successful public deployment.
2. You can edit DNS records for the domain.
3. You have chosen one canonical hostname, such as www.example.com or example.com.
4. If the domain is for production traffic, you are viewing or targeting the production app.

For the simplest DNS setup, use a subdomain such as www.example.com. It can point directly to the app with a standard CNAME record.

Connect in the Dashboard

1. Open the app in the Gencow Dashboard.
2. Select Development or Production with the app-level environment switcher.
3. Open Hosting.
4. In Custom Domain, confirm that the displayed environment and app name are the target you intend to publish.
5. Enter the hostname without a scheme or path, for example www.example.com.
6. Select Connect.
7. Add the exact DNS record displayed by the Dashboard.
8. Return to Hosting and select Recheck DNS until DNS and TLS are active.

The Hosting page always applies domain actions to the exact app currently open. Switch to the production app before connecting a production hostname.

Connect with the CLI

Connect a www hostname to a production app:

gencow domain set www.example.com --prod

Without --prod, the command targets the dev app:

gencow domain set www.example.com

Preview the target and required DNS records without changing anything:

gencow domain set www.example.com --prod --dry-run

If the same domain is attached to the related dev app, preview the move first and then confirm it:

gencow domain set www.example.com --prod --dry-run
gencow domain set www.example.com --prod --yes

Use --app <name> only when intentionally targeting an app other than the one in the local gencow.json.

Configure DNS

Use the exact target printed by the Dashboard or CLI. Examples below use my-app-prod.gencow.app; your target will be different.

Subdomain or www

Create a CNAME record:

Some DNS providers expect the full hostname (www.example.com) in the Name field. Others expect only the label (www). Follow the provider's convention.

A directly connected www.example.com hostname is canonical. Gencow serves it directly and does not redirect it to example.com.

Apex Domain

For example.com, use one of the apex-compatible records printed by Gencow:

Prefer ALIAS, ANAME, or CNAME flattening when the DNS provider supports it. Otherwise, use the current stable edge IP shown by the Dashboard or CLI. Do not copy an IP address from an old guide or another project.

If you use a DNS proxy service, leave the new record in DNS-only mode while Gencow verifies the A or CNAME target and provisions TLS.

Verify DNS and TLS

DNS changes can take time to propagate. Check the selected environment:

gencow domain status --prod

For a dev app, omit --prod:

gencow domain status

The domain moves through these states:

TLS certificates are provisioned automatically with Let's Encrypt after DNS is verified. You do not need to upload a certificate or private key.

After the status becomes active, verify both the page and the intended app:

curl -I https://www.example.com

If dev and production contain visibly different builds, confirm that the custom domain serves the production build before sharing it publicly.

Same-Origin Auth and APIs

An active custom domain is a Gencow-managed app origin. Frontend pages, API requests, authentication callbacks, and realtime connections can use the same origin.

Do not add an active custom domain to frontendOrigins. Gencow adds managed app origins and active custom domains automatically. Use frontendOrigins only when the frontend is hosted outside Gencow, such as on Vercel or Netlify.

When a frontend build embeds an absolute API URL, build it for the intended public origin before publishing:

VITE_API_URL=https://www.example.com bun run build
gencow deploy --static --prod dist/

Move or Remove a Domain

Move a domain between the related dev and production apps only after checking which build should receive public traffic:

gencow domain set www.example.com --prod --dry-run
gencow domain set www.example.com --prod --yes

Disconnect a production domain:

gencow domain remove --prod

Disconnect a dev domain:

gencow domain remove

Removing a domain stops Gencow from routing it to the app. Remove or update the DNS record separately at your DNS provider.

Troubleshooting

Official Gencow domains such as gencow.app, gencow.dev, and gencow.com are not self-service custom domains.

Related References

• Deployment — environments, backend/static deploys, rollback, and CI/CD
• Cloud Plan Limits — plan eligibility and capability enforcement
• CLI Reference — all gencow domain flags
• Troubleshooting — symptom-first deployment and auth checks