Hostnames and rules
Customize the URLs used by each of your services for easier discovery and collaboration
Hostnames
Each public service in each environment has a unique hostname that can be built from components, including:
The service name (for example, "frontend")
The application name (for example, "voting app")
The environment ID (for example, "production" for a permanent environment or "ted8a14" for an ephemeral environment)
Your domain (for example, example.com or .rls.sh)
Configure your hostnames in the Application Template file. For example, you might want longer hostnames to make it easier to identify from the name exactly which application and environment you're viewing, or shorter hostnames for easier readability and sharing.
To change the default hostname for an application, navigate to the Settings tab for the application and press Edit in the "Application Template" section.
In the code editor that opens, look for the hostnames key, as shown below.
The default hostname looks something like this: <service.name>-<example-app>-<env_id>-<domain>.
The hostname starts with the service name followed by the application name (for example, frontend-voting-app), then a unique random environment ID (for example, ted1bc4 for an ephemeral environment or production for a permanent environment), and finally, your domain name (for example, example.com).
A service called "frontend" that is part of an application called "voting-app" running in an environment with the ID "ted1bc4" on the free tier of Release would look like this: https://frontend-voting-app-ted1bc4-.rls.sh.
You can customize your hostname by adding hard-coded strings or by adding or removing the available templated variables. For example, if you don't want the environment ID in the hostname, you can change the template string in the Application Template file to frontend-voting-app.${domain}.
Click Save as new version and the next time you deploy, you'll see the updated custom hostname.
Note that customizing the hostname URL in the default Application Template file will affect the default hostname of every other environment that is instantiated from this global default.
If you have a starter account, you will need to leave the domain variable in place so that you can view your environments on the rls.sh domain.
Rules
Rules provide an alternative way to define entry points to your services and let you assign multiple endpoints for a single service. Rules are based on the NGINX Ingress Controller.
When you define rules in your Release configuration, Release will automatically set up an NGINX Ingress deployment to handle routing for you.
Rules consist of a service, one or more hostnames, and a path. The full schema is shown here.
As an example, you could set up the following rules for an application with a backend authentication system served from /auth/ and a frontend GraphQL server from /graphql using the following rules:
You could also "mix and match" visibility rules which allow you to host private URLs:
Choosing between hostnames and rules
If you only want to configure how your hostnames look and behave, changing the hostname template is the simplest option. Use rules for more complicated cases, such as when you need to assign more than a single endpoint to a specific service.
Note that you can't use both hostnames and rules at the same level of your configuration. For example, you cannot define both rules and hostnames in your default Application Template file, but you can define default hostnames and then override them with rules inside the environment_templates section.
Last updated
