> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stackshift.cloud/llms.txt
> Use this file to discover all available pages before exploring further.
# Publish a VPS web app
> Map a StackShift HTTPS hostname to one selected HTTP port on a full-root Compute VPS.
## Goal
Give an HTTP app on a VPS a managed public HTTPS address without a guest agent or dedicated guest IPv4.
## Prerequisites
* A running Compute VPS with the Publishing tab enabled.
* An HTTP service listening on a guest address the compute host can reach. A service bound only to guest 127.0.0.1 needs reconfiguration.
## Workflow
Open Compute → your VPS → Publishing → Web publishing → Publish app.
Enter a Hostname label such as myapp. The dialog previews myapp.compute.stackshift.cloud.
Enter the App HTTP port used by the service or guest reverse proxy. Add Allowed client IP ranges only if you want to limit visitors.
If the app or guest proxy routes by hostname, add the previewed hostname to that app before publishing.
Click Save publication. When the route shows Configured, open its HTTPS link from the publication card.
## Choose the correct guest port
* For an app listening directly on port 3000, enter 3000. For an app behind Coolify or Dokploy, enter the HTTP port exposed by its guest reverse proxy rather than an internal container-only port.
* The destination must speak HTTP. Do not enter a TLS-only HTTPS port such as 443 unless that port actually accepts plain HTTP. StackShift provides HTTPS to visitors at the edge.
* The service must listen on an address the compute host can reach. A listener shown as 127.0.0.1:3000 or \[::1]:3000 is guest loopback only; configure it to listen on the guest network address before publishing.
* On the VPS, run the command below to inspect listening addresses and ports. Check the app or proxy configuration if the expected port is absent.
```bash theme={null}
sudo ss -ltnp
```
## Fields in the Publish app dialog
* Hostname label: the unique first part of your StackShift address. Enter myapp, not a full URL. The resulting address is myapp.compute.stackshift.cloud.
* App HTTP port: the port on this VPS that StackShift should connect to. It must be a number from 1 to 65535.
* Allowed client IP ranges: optional CIDRs separated by spaces, commas, or new lines. Leave empty for a public app. A single IPv4 address uses /32 and a single IPv6 address uses /128.
* Save publication queues the route. The publication card then shows its URL, guest port, route status, and app health.
## Request and TLS path
A browser connects to the StackShift edge over HTTPS. The edge selects the hostname and forwards the HTTP request to the port you selected on the VPS. The original Host name reaches the guest application, so a guest reverse proxy can route it to the right app.
TLS ends at the edge. WireGuard protects the edge-to-host leg; the final hop to the selected guest port is HTTP. If your application needs its own end-to-end TLS policy, design for that separately.
## Direct apps, Coolify, and Dokploy
* For a directly hosted app, publish the HTTP port where it listens on the VPS.
* For Coolify or Dokploy, add the new StackShift hostname to the app or proxy configuration and publish its guest HTTP proxy port. A container-internal port is not enough unless the guest exposes it on a host-reachable address.
* Publishing a new name does not take over an existing customer domain, certificate, or Coolify/Dokploy ingress rule. Keep existing DNS in place until you deliberately migrate a domain.
## Reading route and health status
* Pending means StackShift is applying the route. Configured means the edge and compute host applied it. Open the HTTPS address to confirm the intended app responds.
* App health reports a probe of /. The edge tries HEAD and uses GET if HEAD is unsupported. Any response below HTTP 500 counts as healthy, including login redirects and 4xx responses; it does not describe every page of the app.
* After an edit, health resets to unknown until a new probe runs. An offline VPS is not routed. Unpublish withdraws the edge hostname through reconciliation and removes attached custom-domain routes.
## Change or remove a route
* Choose Edit on the publication card to change its guest HTTP port or client CIDRs. The hostname label stays the same.
* Choose Unpublish to remove the StackShift hostname and any custom domains attached to that publication. This leaves the app running inside the VPS.
## Scope
* A web route publishes HTTP traffic for one guest port. It does not grant arbitrary TCP access to that VPS.
* The relay uses an HTTP reverse proxy. Request bodies and protocol upgrades follow that HTTP path; application-level behavior remains the responsibility of the service running inside the VPS.
* Client CIDRs are optional. At the edge, the restriction is applied before the request is forwarded. An empty list makes the published hostname public.
## Expected result
Requests to the new HTTPS hostname reach only the selected app port on the selected VPS.
## Common failures
* A 502 or unavailable app after the route is configured can mean the selected guest port is wrong, the app is down, it listens only on guest loopback, or the guest firewall blocks the compute host.
* A default page or wrong Coolify/Dokploy app suggests its proxy does not recognize the published Host name. Add that hostname in the app/proxy configuration.
* A 403 can come from the route’s client IP restriction. Check the actual source IP seen at the edge and the configured CIDRs.
## Related guides
Prove ownership with DNS TXT, point A or AAAA directly at the edge, and attach the hostname to an existing web publication.
Use Edge SSH to manage the VPS remotely and Web publishing to expose an app already running behind Coolify or Dokploy.
Use the Publishing status and connection symptom to check the right guest port, SSH key, DNS record, or client IP restriction.