Networking and ports

Public services

A public service answers at https://{service}-{project}-{organization}.smartalfred.com, with HTTPS. Add your own domains too. Visitors reach the nearest server running it.

Other organizations' apps are on smartalfred.com too, so cookies aren't shared across it: a cookie your app sets with Domain=smartalfred.com is kept to its own address. To share cookies between your services, give them your own domain.

A visitor's request goes over HTTPS to Alf's edge, which holds your address, your domains and their certificates. From there it travels over the connection the nearest server running the service keeps open to Alf, so nothing on the internet connects in to the server. The server wakes the app if it's asleep, holding the request meanwhile, and passes it to the app's port in its own virtual machine. A public TCP or UDP port is the other way in: it skips the edge and goes straight to the server.

Private services

Choose Private under the service's settings (or when creating it): it gets no address on the internet. The project's other services reach it as name:port, e.g. db:5432. Use this for databases, caches, queues and workers. A private service always runs, unless you let it sleep: then a call from the project's other services wakes it.

To reach a database from outside the project (from your laptop, or another platform), open a public port for it (TCP or UDP): an address like db-shop-acme.tcp.smartalfred.com:20431, open only to the IP addresses you list.

WebSockets

A public service's address takes WebSockets as it takes anything else: connect to wss://{service}-{project}-{organization}.smartalfred.com and your app sees an ordinary upgrade. Your own domains work the same way. Nothing has to be switched on.

A service with an open socket counts as in use, so it won't fall asleep underneath one. It can sleep again once the last socket closes.

Two things worth knowing:

For a protocol that isn't HTTP or WebSocket — a database, a game server — open a public port instead.

The project network

All services of a project share a private network:

Project shop runs on two servers, fsn-1 in Falkenstein and nbg-1 in Nuremberg. On fsn-1, web calls db:5432; on nbg-1, api calls db:5432 too, and a private worker runs. The two servers' parts of shop's network are joined by an encrypted WireGuard tunnel over UDP 51820, set up by itself, so the names work on whichever server a service runs. Another project's app on fsn-1 can't reach shop's services. A call to an app goes through its server's front, which keeps it with the app's requests and wakes the app if it sleeps; db, a database, is reached at its container directly.

Ports

Your app listens on one port inside its container:

If a deploy ends with "didn't open its port in time", the app listens on a different port than the service says. See Troubleshooting.