Documentation
Services
An app runs one service — your code — optionally alongside a managed Postgres. This page is about how that service is reached, and the port and naming rules it lives under.
Where the service is reached
The service serves the app's own URL. There is no exposure setting to choose and no routing to configure: traffic that arrives at the app's address, once it has passed the access check, reaches your service on the port it listens on.
- Its address is the app's address — see Domains for the default hostname and for pointing your own at it.
- Who reaches it is the app's access setting, applied before the request gets to your code — see Access.
Ports
Your service listens on one port, detected from the repository where we can work it out and editable when we cannot. Two ports are reserved and cannot be used:
| Port | Reserved for |
|---|---|
| 80 | The router that puts your service behind the app's URL. |
| 5432 | The app's database, when it has one — see Database. |
The database port matters more than it looks. The service and the database share one network namespace, so if the service won the race for that port, the app would be talking to itself while believing it was talking to its database. The port is refused rather than negotiated.
Naming a service
Lowercase letters, digits and hyphens; start with a letter or a digit; at most 32 characters.
The rule is this strict because the name is not decorative — inside the app it becomes a service unit, a container name, a log path and a matcher label in the router. An uppercase letter or a space does not survive all four.