Custom Domains

QuikDB can serve an approved customer-owned hostname, such as app.example.com, in front of a QuikDB deployment. Requests stay on QuikDB's managed routing path, and HTTPS is provisioned and renewed for the approved hostname.

Limited availability

Custom-domain onboarding is currently available only to selected supported users. Public self-service setup will open later. A plan allowance does not by itself enable the feature or guarantee onboarding. To request access, contact QuikDB support with the deployment and hostname you want to connect.

What QuikDB Manages

For an approved hostname, QuikDB coordinates:

• attachment to the selected QuikDB deployment;
• the exact DNS record required for that hostname;
• DNS and route verification;
• HTTPS certificate provisioning and renewal;
• routing through the QuikDB edge to healthy application replicas; and
• status checks, repair and safe disconnection when needed.

Both a root domain and a subdomain can be reviewed. DNS-provider capabilities differ, so QuikDB confirms the supported record for the requested hostname during onboarding.

Current Plan Allowances

Tier	Custom Domains
Hobby	Not available
Builder	1
Startup	5
Team	Unlimited

These are plan limits, not a public self-service promise. The limited-availability onboarding requirement applies to every tier while the feature is being prepared for general release.

Supported-User Onboarding

1. Keep the deployment's *.quikdb.net URL live and confirm the application is healthy.
2. Contact QuikDB support with the deployment and exact hostname you want to use.
3. QuikDB reviews the hostname and sends the exact DNS record for that onboarding.
4. Your DNS administrator applies only that supplied change.
5. QuikDB verifies DNS, provisions HTTPS and confirms when the hostname is active.

Do not look for an origin

Do not point DNS at an IP address, container, runner, tunnel, replica, load balancer or hostname that appears to be the deployment's origin. These are internal, can change, and are not a supported public interface. Do not reuse a value from another customer or an old example. Use only the exact DNS record QuikDB supplies for your approved hostname.

Before changing DNS, check whether the same hostname or root domain also carries website, email, verification or other records. Do not replace, proxy or delete existing records unless QuikDB has reviewed the hostname and explicitly included that change in the onboarding instructions.

How Routing and HTTPS Work

After the approved DNS record is verified, traffic follows the managed path:

User request → approved hostname → QuikDB edge → healthy application replica

QuikDB terminates HTTPS at the managed edge and maintains the certificate. You do not need to install a certificate on an application container or discover its origin. Origin addresses and individual replicas may change without requiring a customer DNS change.

Changes and Removal

Contact QuikDB support before moving an approved hostname to another deployment, changing its DNS record or removing it. QuikDB will detach the route and confirm which managed record can be removed. DNS and certificate status may take time to converge after a change.