Every deployment you make on our platform, whether you are using our clients, GitHub integration, or our powerful API, receives its own unique URL.
These deployment URLs share a global common namespace with all other customers: *.now.sh. To present these deployments to your end users, you then alias those URLs to your definitive domains.
Today we are introducing a new add-on: Custom Deployment Suffix. This add-on allows you to replace .now.sh everywhere with a custom domain of your choosing, giving your team further isolation, privacy, and security for all new deployments.
As an added bonus, if you enable this feature you will receive a forever free .sh domain*. We have even configured our own company's suffix to be `zeit.sh`. Let's take a look at what it took to set that up.

Activating the add-on

Head to your account settings page by clicking your avatar on the top-right section of the screen, and then the account or team the add-on is meant for.
Activate the add-on by toggling it on within the Add-Ons section of your settings.

Activating the Custom Deployment Suffix add-on from the account settings page.

Once the add-on is enabled, head to the next and final step - setting it up. Do this by clicking on the SETUP link within the add-on box.

Your Free .sh Domain

The add-on configuration page allows the selection of any domain previously configured on the account or team before (by running now domains add or transitively by executing now alias).
We also empower you to instantly search and buy any domain of your liking without leaving this step.
The best part? If you buy a .sh domain - normally priced at $46 - it's on us:

`.sh` is the TLD of deployments.

Once the configuration is saved, our backends will ensure all the requirements are met for its prompt application.
This process might take a few minutes, but we will dispatch an email as soon as it is ready.

You'll be told when your custom suffix is ready, if not immediately.

At this point, all new deployments will receive their new suffix:

Deploying after enabling the add-on will result in a deployment URL using your custom domain as the suffix.

How does it work?

How do we make sure this process goes this smoothly, in consideration that: the domain that did not previously exist was acquired, that DNS propagation delays are significant, and a new wildcard certificate has to be issued by Let's Encrypt?
All without introducing any downtime to concurrent deployments that are being made by your team?

Ensuring the Correct State

Whenever you select a domain as your custom domain suffix, our API validates that the initial requirements are met.
Only domains that are verified (i.e. the domains you own) and those that point to our nameservers are accepted.
Once the change is saved to our database, our backend begins a loop that ensures that all the dependencies of the suffix are met:
  • The DNS is correctly configured and propagated
  • A wildcard certificate is issued
  • The configuration is propagated across our datacenters
During this process, all deployments will continue to be created with now.sh as a suffix in order to ensure the correct health of the service at all times.
Furthermore, if any of the dependencies are undone later on (for example, if you were to delete the domain or certificates manually), the deployment suffix will be deactivated until the correct conditions are applied again.

Future Developments

Using your own domain for deployments is a very important step for your team. We just showed how you and your team can gain your own space within the cloud, securely, and automatically.
All with a setup process that involves just a few clicks.
In the future, you can expect more powerful settings and features to be enabled on top of your custom domain suffix, such as only allowing specific IPs or subnets to access the direct deployment URLs (this feature is currently only available to custom enterprise plans).
We hope you find this feature useful and would love to hear your feedback.
* The chosen `.sh` domain is free as long as the add-on is enabled. If the add-on is disabled, the domain will be charged for full-price at the renewal date unless removed. If the add-on is enabled for the purpose of obtaining the free domain, please note that disabling the add-on will incur in the charge of use by the first month of the add-on.