One deployment. Real client isolation. One bill.
SecureRedirector runs branded URL redirection for many clients from a single instance. Each client team owns their own domains, rules, and click data — without a separate Bitly workspace, a separate Rebrandly plan, or a separate nginx host per client.
Reply within one business day. Bring your client domains.
The agency problem with conventional link SaaS
If you manage URL redirects for ten clients, you have three structural options today and all three get expensive fast:
- One SaaS account per client — duplicate billing, duplicate logins, duplicate compliance reviews. You become a procurement function for short links.
- One shared workspace inside a SaaS — usually capped at a small client count on lower tiers, or priced per workspace at higher tiers, with no real data boundary between clients in the shared workspace model.
- Per-client custom nginx — works for ten clients, falls over at fifty, and turns every certificate renewal into operations work.
SecureRedirector exists because none of those scale cleanly past about five clients. The agency model is the use case the product is designed around — not retrofitted from a single-team SaaS.
How tenant isolation actually works
One SecureRedirector deployment hosts many teams. A team is the unit of isolation — one team per client is the canonical agency pattern. Inside the team, the client owns their own surface; across teams, they share nothing implicitly.
Domains belong to a team
Every branded domain — links.client-a.com, go.client-b.com — is registered to exactly one team. The provisioner picks it up from that team's record, generates the nginx site config, and runs Certbot for the TLS certificate. There is no shared domain pool.
Rules belong to a team
Redirect rules, short-link slugs, and per-rule HTTP status codes are stored against the owning team. A query in the management portal or via the API is scoped to the requesting team. Team A cannot accidentally read Team B's rules.
Click data belongs to a team
Every click event is tagged with the team that owns the domain. Analytics queries are filtered at the data-store level — not at the UI. If you wire click events into a warehouse or analytics pipeline, the team tag travels with the row, so cross-tenant aggregation requires explicit operator privilege.
Operators are above the teams
The agency itself runs as an operator role with deployment-wide visibility — useful for support, capacity planning, and onboarding new clients. Operator access is logged. Clients do not see each other; operators see all teams.
White-label specifics
What you can hand off as your own surface, and what we still ship under our brand. We are honest about the boundary — this is v1 white-label, not a fully reskinned product.
| Surface | White-labeled today | Notes |
|---|---|---|
| Branded short URLs | Yes | Every link served from the client's domain. No SecureRedirector mention. |
| Click data | Yes | Stored against the client's team. Exportable to the client's warehouse. |
| Management portal (client view) | Partial | Client portal subdomain you choose; client sees their team only. Custom logo / palette on managed-hosted agency plans. |
| Email notifications | Configurable | Sender domain configurable per agency on managed-hosted; fully controlled on self-hosted. |
| Authentication | SSO-friendly | Per-team identity provider on the roadmap for managed-hosted agency plans; self-hosted today supports SAML / OIDC via standard Identity configuration. |
The operational story
The reason this works at agency scale is that the shared infrastructure is genuinely shared. Adding the eleventh client doesn't double your ops load.
- One deployment to patch. Upgrade once, every client benefits.
- One certificate-renewal pipeline. Certbot's systemd timer renews every domain across every client; failures surface in the deployment health-check output.
- One alerting surface. Failed redirects, missed heartbeats, and capacity events flow into one alerting channel that you triage as the agency operator.
- One backup pipeline. Database and rule-set backups are deployment-wide; restoring one client's data is a scoped operation against the same backup.
- Cron-driven domain provisioning. Add a domain in the portal, the provisioner picks it up within minutes, generates the nginx site config, runs Certbot, enables HTTP/2. No operator touches nginx for routine adds.
FAQ
- How real is the tenant isolation?
- Every domain, rule, short-link slug, and click-event row is tagged with the team that owns it at the database level. Queries from the management portal and the analytics store are filtered by the requesting team — there is no implicit cross-tenant view. The team is the security boundary, not a UI filter on top of a shared dataset.
- What does white-label mean here?
- Two layers. The data layer is white-label by default — each client team owns its domains, click data, and rules, and those domains carry the client's brand (links.client-a.com, not anything that mentions SecureRedirector). The UI layer is partial: client portal access shows your branded chrome on the management portal subdomain you choose. Full UI white-labeling (custom logo, custom subdomain, custom palette) is on the roadmap for managed-hosted agency plans.
- How many clients can run on one deployment?
- There is no hard cap. The practical ceiling is set by your VM size for self-hosted deployments and by the tier you pick for managed-hosted. Most agencies onboard their first ten clients on a small VM without noticing the load.
- Can a client manage their own rules, or does the agency operator have to?
- Both models are supported. You can give a client team portal access to manage their own domains, rules, and slug inventory directly. You can also keep all rule management operator-side and expose only the analytics view to the client. The choice is per team — different clients can be on different models within the same deployment.
- What does the migration from per-client SaaS subscriptions look like?
- Most agencies migrate one client at a time over two to four weeks. For each client: stand up the team, import their existing link inventory from their current vendor (Bitly / Rebrandly / Short.io), point their branded domain DNS at SecureRedirector, and run in parallel for 48–72 hours before cancelling the per-client SaaS subscription. After the second or third migration the playbook is mechanical.
- How does pricing scale with client count?
- Pricing is set by the deployment footprint and team count, not per-link or per-click volume. Adding clients adds operational overhead, not a separate billing event per client. The exact numbers depend on hosted vs self-hosted, expected click volume, and support tier — we will quote within one business day.
Running redirects for many clients?
Send us a quick sketch of the shape — how many clients, how many domains each, hosted or self-hosted — and we will quote within one business day.