Test domain

# Structure

Test domains follow a predictable naming pattern: {environment}.{region}.frbit.app, where environment is the unique app environment identifier, region indicates the data center location, and frbit.app is the fortrabbit root domain.

{{ environment }}.{{ region }}.frbit.app

environment — ID, short unique identifier
region — data center region ID, geo location
frbit.app — fortrabbit associated root domain

• Example: https://my-app-abc123.eu-1wa.frbit.app
• Live code example: {{app-env-id}}.{{region}}.frbit.app (login required)
• TLS is included. The test domain is always served over HTTPS.

# Use cases

Test domains serve multiple purposes in development and deployment workflows: immediate browser preview after deployment, easy team sharing, staging environment testing, and automation integration.

• Test — open the environment in a browser after deploy without any setup.
• Share work in progress — send the test domain to a colleague or client.
• Staging environments — use the test domain for feature development preview.
• CI/CD pipelines — reference the test domain in automated tests or health checks.

# Limits

Test domains have two important constraints: the environment identifier cannot be changed after creation, and they are not suitable for production use with customer-facing applications.

• The name cannot be changed. The app-env-id part of the test domain is fixed at environment creation time.
• The test domain is not a replacement for a production domain. For a customer-facing address, add an external domain.