Permalinks on PMSS

Every active Pulsed Media seedbox and storage box gets a permalink — a permanent hostname under mcx.fi that points to your service and follows it when we move it to a different server. Bookmark it, put it in a webhook, use it as an API base; it does not change when your underlying server does.

The permalink is a short hash label, so it carries no username and no account number in the address. You compute your own from your service ID — nothing has to be looked up or requested. Service IDs are not secret, so treat the label as a stable public alias for your service, not as something that hides which service it is.

The two permalink forms

Form	Looks like	Points to
Service permalink (one per service)	`{hash}.mcx.fi`	the single server your service runs on
Cluster permalink (accounts with 2+ services)	`{hash}.mcx.fi`	all of your servers, in round-robin

Both are live in DNS today. Both labels are a truncated SHA-256 hash — nothing else. The service permalink also serves your public web folder over HTTP; the cluster permalink resolves, but on most servers it does not serve web content — see web hosting and the note below.

Service permalink — one stable hostname per service

Each active service has its own hostname built from its service ID. The label is the first 16 hex characters of a SHA-256 hash:

label = first 16 hex chars of  sha256("mcx.fi:service:<your service ID>")
url   = <label>.mcx.fi

The service ID is the number in your client area product page URL — clientarea.php?action=productdetails&id=<service ID>. Compute your permalink on any machine with sha256sum:

printf 'mcx.fi:service:12345' | sha256sum | cut -c1-16
# -> a hex label; your URL is <label>.mcx.fi

Replace 12345 with your own service ID. The hash uses no secret — the same input always gives the same label — so your permalink is stable for the life of the service. When we migrate your service to another server, the record updates to the new server's address automatically; the hostname stays the same.

Because this label is tied to the service and not to the server it currently sits on, it is the right hostname to hand to anything that has to keep reaching your service across a move: a webhook target, an API base, or a self-hosted S3 endpoint you run on the box. Point the client at <your-service-label>.mcx.fi and the port your service listens on, and the address behind it keeps tracking your service when we relocate it. This service permalink is the per-service form; the cluster permalink below is the whole-account form.

Cluster permalink — round-robin across your servers

If your account has two or more active services, on the same server or on different ones, you also get one cluster permalink built from your client ID:

label = first 16 hex chars of  sha256("mcx.fi:customer:<your client ID>")
url   = <label>.mcx.fi

This hostname carries an address record for each of your servers, handed out in rotating order, so connections spread across your servers — a simple round-robin at the DNS level. It gives you one name that reaches your whole fleet, with the lookup landing on a different server each time.

This is plain round-robin DNS, not a health-checked load balancer and not an edge CDN. There is no failover: a server that is temporarily down stays in the rotation until it is removed on a later rebuild. It spreads load; it does not detect outages.

On most servers the cluster permalink does not serve your web content. It resolves — a lookup lands on one of your servers — but a server serves your ~/www/public/ on it only when it runs current PMSS and has your account's client ID recorded locally, and most servers do not have that. Elsewhere the server answers with its own default page. For web links, use a service permalink, which does serve your content, and treat the cluster permalink as a DNS-level convenience for non-web use.

What gets served at these hostnames

Your service permalink resolves to the server your service runs on. On the current Pulsed Media platform it serves your public web folder, ~/www/public/ — the same content as your per-user web hosting. So a file at ~/www/public/report.pdf is reachable at http://<service-label>.mcx.fi/report.pdf.

Your cluster permalink serves the same folder only on servers where cluster serving is in place; elsewhere a web request to it gets the server default page — see the note in the cluster section above.

Web serving here is over plain HTTP by default. A browser opening https:// on these names will warn, because the server's TLS certificate is issued for its own hostname, not for the mcx.fi label. To get a valid certificate for your service permalink, run ~/bin/createWebPublicCerts once over SSH. It requests one Let's Encrypt certificate for your service permalink only; it is normally in place within a few minutes and renews automatically. Every public certificate is published in Certificate Transparency logs, which anyone can search, and the permalink contains no username. To cover your USERNAME.SERVER.pulsedmedia.com subdomain as well, run ~/bin/createWebPublicCerts --with-username-hostname and type yes when asked: that publishes your username in those logs for good, and requesting the permalink-only certificate later does not remove it. A server that has not yet installed the PMSS update of 7 October 2026 covers both names without asking. The cluster permalink is not covered, because a round-robin name cannot pass the certificate check from a single server; for HTTPS on that, use your server's own hostname.

Why the permalink is stable

The label comes from your service ID, which never changes, so the hostname is permanent. The address behind it is rebuilt from live account data, so it tracks reality: a migration to new hardware updates the address, a cancelled service drops out. The records carry a long time-to-live (about a day), so after a migration it can take up to a day for every resolver to see the new address. The trade-off is deliberate — the permalink is meant to be stable, not instant.

Privacy

The permalink is a hash label, so your username is not in the address. Only the hash and the IP are ever published to DNS — your service ID, client ID, and username stay on our systems and are never sent out. The hash is computable rather than secret: anyone who knows a service ID can derive its label, and the address it points to is public DNS like any hostname. Service and client IDs are small numbers, so the reverse also works: trying IDs in turn finds the one behind a label. Treat these permalinks as public links, not as private ones.

Included with every service

A permalink comes with every active seedbox and storage box at no extra cost, on the same PMSS platform that runs the fleet. Put a file in ~/www/public/, hand out the mcx.fi permalink, and it keeps working when your service moves.