Quick Answer
For multi-tenant SaaS, start simple but centralize tenant resolution early. Slugs, tenant subdomains, and custom domains are not just URL styles; they become onboarding, routing, support, and lifecycle objects. The safest design lets the product resolve a tenant from multiple entry patterns without scattering URL parsing across the codebase.
SaaS onboarding is full of small repeated steps.
One of them is giving a new customer a reliable entry point.
If the product can create a workspace automatically, but the customer access entry still needs manual work, onboarding is not fully automated.
Decision Table
| Choice | Best for | Watch out for |
|---|---|---|
| Path slug | Early products, QR flows, simple deployments | Do not scatter slug parsing everywhere. |
| Tenant subdomain | Branded tenant URLs and cleaner tenant-level routing | Plan wildcard DNS, SSL, and support workflows. |
| Custom domain | Customers who need their own branded hostname | Requires verification, status tracking, and lifecycle management. |
The Short Answer
A tenant onboarding subdomain workflow should create a managed entry when a customer workspace is ready, assign ownership, set status, point to the correct destination, record changes, and retire or pause the entry when the tenant lifecycle changes.
The Basic Flow
A simple tenant workflow looks like this:
- Customer signs up or is created by sales.
- Workspace is provisioned.
- Tenant entry is created.
- Destination points to the workspace.
- Status becomes active.
- Customer receives the access entry.
- Access statistics and changes are monitored.
The entry should be part of the onboarding process, not an afterthought.
What the Entry Should Store
For each tenant entry, store:
- Tenant name.
- Workspace ID.
- Hostname.
- Destination.
- Owner team.
- Customer success owner.
- Status.
- Created date.
- Last changed date.
- Last access time.
This helps support, sales, success, and engineering understand the customer entry quickly.
Status Matters
Tenant entries should not only be active or deleted.
Use states:
- Draft.
- Active.
- Suspended.
- Review.
- Retired.
These states mirror customer lifecycle better than raw DNS records.
When OpenAPI Helps
OpenAPI is useful when tenant creation is repeatable.
The product can call an API to create the entry, update the destination, or pause the route when the customer status changes.
This reduces manual work and keeps the entry lifecycle aligned with the customer lifecycle.
What to Avoid
Avoid:
- Creating tenant entries without owner context.
- Reusing vague names.
- Leaving trial tenant entries forever.
- Forgetting to pause entries after cancellation.
- Hiding access history in unrelated systems.
These issues become expensive when the customer base grows.
Final Thought
Tenant subdomain automation is not only about creating a hostname.
It is about making the customer access point part of the product lifecycle: created, visible, updated, monitored, and retired with context.
FAQ
Should an early SaaS start with slugs or subdomains?
Most early SaaS products can start with slugs as long as tenant resolution is centralized and future subdomains are not blocked.
When do tenant subdomains become useful?
They become useful when tenant identity, branding, sharing, cookie boundaries, or custom-domain readiness matter to the product.
Where does PushUlink fit in tenant routing?
PushUlink can help teams create, update, track, and retire tenant-facing subdomain forwarding entries through Console and OpenAPI.