Hostly Domains and Domain Fragments
Hostly uses domains to address workspaces and services uniquely on the internet.
DNS in brief
The Domain Name System, or DNS, translates readable domain names into technical network and routing information.
When a user opens app.example.hostly.ninja, DNS first ensures that the request reaches the Hostly infrastructure. Hostly then maps the request to the matching service and forwards it there.
No custom DNS records are required for domains provided by Hostly. Everything is fully configured and ready to use from the moment the service is deployed.
Four central terms
| Term | Example | Meaning |
|---|---|---|
| Workspace domain fragment | example | The name part assigned to a workspace. |
| Workspace domain | example.hostly.ninja | The full domain of the workspace. |
| Service domain fragment | app | The name part assigned to a service. |
| Service domain | app.example.hostly.ninja | The publicly reachable domain of the service. |
The service domain always follows this pattern:
<Service-domain-fragment>.<Workspace-domain-fragment>.hostly.ninjaWorkspace domain fragment
The workspace domain fragment is globally unique. Therefore, only one workspace worldwide can use, for example, example or example.hostly.ninja.
An account with multiple workspaces needs its own globally unique workspace domain fragment for each workspace.
The workspace and its domain fragment currently cannot be renamed.
Service domain fragment
The service domain fragment must be unique within the workspace.
Example:
app.example.hostly.ninja
api.example.hostly.ninja
status.example.hostly.ninjaAnother workspace may use the same service domain fragments:
app.data.hostly.ninja
app.example.hostly.ninjaA service may also use the same fragment as its workspace:
example.example.hostly.ninjaHostly always creates exactly one additional domain level for the service.
Character rules
The following characters are currently allowed for workspace and service domain fragments:
Alphanumeric: a-z, 0-9Uppercase letters are automatically converted to lowercase.
Changes and reservation
The workspace domain fragment cannot be changed.
A service domain fragment can only be changed through a deployment change. There is no automatic redirect from the old service domain to the new one.
The service domain fragment remains reserved throughout the entire service lifecycle. Only final deletion releases it for reuse.
HTTP and HTTPS
When deploying a service, you must select how users should access the service. The available options are HTTP and HTTPS.
HTTPS
Every service can use the built-in SSL or TLS feature. A deployment with this feature enabled automatically receives a Let's Encrypt certificate and upgrades HTTP traffic to HTTPS.
The benefit is that users of the service get an additional layer of connection security, and browsers show users that the connection is secure.
The default deployment configuration is HTTPS. We recommend this setting for most users.
Reachability:
app.example.hostly.ninja -> https://app.example.hostly.ninja
http://app.example.hostly.ninja -> https://app.example.hostly.ninja
https://app.example.hostly.ninja -> https://app.example.hostly.ninjaThe public port for HTTPS traffic is 443.
HTTP
The connection for users of the service is not additionally secured, and browsers show users that the connection is not secure.
We recommend this setting only for users who understand the risks.
Reachability:
app.example.hostly.ninja -> http://app.example.hostly.ninja
http://app.example.hostly.ninja -> http://app.example.hostly.ninja
https://app.example.hostly.ninja -> error 404, page does not existThe public port for HTTP traffic is 80.