Each service is assigned a port, and a domain name points at that port. Understanding those two pieces separately makes almost every connectivity problem diagnosable.
Your container port
Open the Startup tab to see the port assigned to your service. That is the port your application must listen on, and it is the port the proxy forwards traffic to.
Two rules follow from this:
- Your app must listen on all interfaces —
0.0.0.0or::, neverlocalhost. - The app must start on its own. If something in your code starts the server, and your startup command also does, the second attempt fails with a port conflict.
The Network tab shows your service's network configuration if you need to confirm how it is wired up.
Your free subdomain
Every plan includes a custom subdomain at no extra cost. Once your app answers on its port, point the subdomain at the service from the service settings — no DNS record to create, nothing to renew, no recurring cost.
That subdomain is served over HTTPS with a valid certificate, so browsers will not warn your visitors. There is nothing to configure for the certificate itself.
Use it for what it is good at: staging, bots with webhooks, anything you want reachable on a stable address for as long as you keep the plan.
Bringing your own domain
You can point your own domain at the service. Two records are involved:
| Record | Points to | Purpose |
|---|---|---|
A | the address shown on the service | direct traffic to your container |
AAAA | the IPv6 address shown on the service | traffic over IPv6 |
CNAME | your SentinelX subdomain | alternative to the A record |
DNS changes take time to propagate. Until the record resolves anywhere, the browser reports a DNS error rather than a connection error — a useful distinction, because it tells you the problem is upstream of your container and your app is not involved at all.
Once the domain resolves, certificate issuance is handled for you. Give it a few minutes after DNS propagates, and re-check rather than assuming a failure.
One service, one port
A single container is addressed by a single port. If your app needs to serve several distinct hosts or paths, route on path rather than binding a second port — for example, /api and /webhooks behind one listener.
Running additional listeners does not make them reachable unless each is separately exposed, and it makes memory use harder to reason about. One process, one port, one clear entry point is the pattern that stays debuggable.
Diagnosing connectivity
| Symptom | Most likely cause |
|---|---|
| DNS error, nothing loads | record not set, or not propagated yet |
| Connection refused | nothing listening on the port |
| Connection resets immediately | listening on localhost instead of all interfaces |
| 503 from the proxy | container stopped, or crashed on start |
| Certificate warning | custom domain added before DNS resolved |
Check the Console first in every case. If your app logged a listening address, the problem is somewhere between it and the browser rather than inside your code.