Endpoints and routing
Route application traffic without turning every service into a networking project
Expose app services through technical domains, custom routes, managed HTTPS, redirects, HTTP basic auth, and published ports from the same Wodby workflow.
Application delivery does not stop when workloads are running. Teams still need browser routes, internal service access, redirects, preview endpoints, TCP ports, and security controls. Wodby keeps those routing decisions close to the app service so teams can expose the right surface without manually rebuilding edge configuration for every environment.
Create routes for the services that need to be reachable
Routes connect external traffic to the app service and port that should handle it.
Wodby can generate technical routes on Wodby-managed domains, which gives teams an immediate endpoint for testing, previews, and environment-specific access. Routes remain attached to the app service, so the routing surface stays visible next to the service configuration it depends on.
- Expose only the services and ports that need external access.
- Use technical routes for fast environment access without waiting on DNS changes.
- Keep route history and configuration close to the app instance and service.
Attach custom routes when the app needs its real domain
Production traffic, customer previews, and branded environments often need custom hostnames.
Custom routes let teams connect their own domains to Wodby-managed app services while still using the same deployment and service model. A primary route can identify the main public endpoint, while redirect routes help consolidate alternate hostnames.
Technical routes
Use generated Wodby domains for immediate access to app environments and services.
Custom routes
Attach your own domains when the service needs a production, staging, or customer-facing hostname.
Redirect routes
Send alternate domains or paths to the preferred route with permanent or temporary redirects.
Automate HTTPS for application routes
Certificate handling should be a platform default, not a recurring operational task.
Wodby provisions and renews Let's Encrypt certificates for supported routes, keeping HTTPS coverage inside the same routing workflow. That gives teams a practical secure-by-default path for technical domains, custom domains, and multi-environment applications.
For more certificate-focused details, see the SSL and TLS feature page.
Tune route behavior without leaving the app workflow
Routing often needs small but important policy choices that should stay visible to the team.
- Redirect HTTP traffic to HTTPS.
- Mark lower environments as no-index.
- Set request body size limits for upload-heavy services.
- Use session affinity when a service requires sticky traffic.
- Rewrite paths when upstream services expect a different URL shape.
- Choose the route that should act as the primary public endpoint.
Protect endpoints before they are ready for everyone
Not every reachable route should be open to the public.
HTTP basic auth can be applied at app, service, or route scope. That makes it easier to protect staging sites, customer previews, temporary QA environments, or internal tools without changing application code.
- Protect an entire app environment when every exposed service should require credentials.
- Protect one service when only a specific runtime surface needs a gate.
- Protect one route when a custom domain or preview endpoint needs a narrower rule.
Publish ports for TCP, UDP, and SSH-style service access
Some services need more than browser traffic.
Wodby endpoints can also publish service ports where the service supports it. This gives teams a controlled path for direct TCP or UDP access, including SSH-style workflows for services that expose file transfer, shell, or similar operational access.
Published ports are managed as part of the application endpoint model, so teams can see which services are reachable and avoid treating non-HTTP access as an unmanaged exception.
Next step
Keep application access attached to the service it exposes
Configure routes, redirects, auth, HTTPS, and ports where teams already manage the app service instead of splitting traffic rules across disconnected systems.