Features
What SecureRedirector does
Five modules built around one job: routing requests for the domains you own to the destinations you choose, with rules you understand. Designed for teams that have outgrown ad-hoc nginx rules and don't want to hand their click data to a third-party SaaS to fix it.
Branded domains
Bring your own domains — apex, subdomains, multiple TLDs. Each domain is provisioned with HTTPS automatically.
Redirect rules
Rules that match on host, port, and path prefix. Default rules cover everything else.
Multi-tenant teams
Multiple teams, each owning their own domains and rules. Built for agencies and multi-brand operators.
HTTPS by default
Let's Encrypt certificates provisioned automatically and renewed by a systemd timer. No certificate juggling.
Short link support
Optional slug → URL layer on top of rule-based redirects. Use when you need a Bitly-style flow too.
What URL redirection actually is
Every time a browser fetches one of your branded short URLs — say
links.yourcompany.com/spring-promo — the server has a
decision to make: where should this request go next? A redirect is the
answer, sent back as an HTTP 3xx response with a
Location header. The browser follows it and lands at the
real destination.
SecureRedirector is the layer that makes that decision. It runs on the domains you already own, reads the incoming request, picks a destination from your rules or short-link table, and sends back the redirect. It is deliberately not a marketing-attribution suite or a link-in-bio product — it does the redirect substrate well and leaves the rest to tools that specialize in it.
Where each module fits
Branded domains
Sets the surface buyers and recipients see. A link on links.yourcompany.com reads as your brand; a link on bit.ly reads as someone else's. The branded-domains module handles registration, DNS guidance, and TLS provisioning per domain.
Redirect rules
The engine that picks the destination. Match by domain, by port, or by path prefix. Set a per-domain default so requests never resolve to nothing. Use 301 or 302 per rule depending on whether the destination is canonical or temporary.
Multi-tenant teams
The boundary model. One deployment, many teams; each team owns its own domains, rules, and analytics. The team is the security boundary — queries are scoped, click data is tagged, and there is no implicit cross-tenant view.
HTTPS by default
The compliance and trust layer. Every domain gets a Let's Encrypt certificate provisioned via Certbot and renewed by a systemd timer. There is no path where a SecureRedirector domain serves over plain HTTP in production.
Short link support
The campaign convenience layer. Per-domain table of slug → URL with optional analytics, applied before the rule engine. Use when you need a Bitly-style memorable URL on top of rule-based routing.
How resolution works
When a request arrives, SecureRedirector resolves the destination in this order. The first match wins:
- If short links are enabled for the domain and the path is a registered slug, redirect to the slug's destination.
- If a port-specific rule matches the incoming port, redirect to its destination.
- If a path-prefix rule matches the incoming path, redirect to its destination.
- Otherwise, redirect to the domain's default destination.
- If no default is set, return
404. Domains never accidentally redirect to a placeholder.
Order is fixed, no DSL, no surprises. The deeper details — including
when to set the rule status as 301 versus 302 —
live on the redirect rules page.
FAQ
- Can I use existing TLS certificates instead of Let's Encrypt?
- Yes. For self-hosted deployments, you can drop your own certificate and key into the nginx site config and disable the automated provisioner for that domain. This covers internal CA chains, EV certificates, and centrally managed wildcards. Hosted plans handle bring-your-own-cert via support.
- How are multi-tenant boundaries enforced?
- Every domain belongs to exactly one team. Rules, short-link slugs, and click data are tagged with the owning team at the database level. Queries from the management portal and the analytics store are scoped to the requesting team — there is no global view that crosses tenants without an explicit operator privilege.
- What HTTP status does SecureRedirector use — 301 or 302?
- You choose per rule and per short-link slug. Use 301 when the destination is canonical and you want link equity to pass for SEO; use 302 when the destination is temporary and you want clients and crawlers to keep checking.
- What happens when no rule matches an incoming request?
- Requests resolve in this order: short-link slug (if enabled for the domain), port-specific rule, path-prefix rule, then the domain's default destination. If no default is set, the request returns a 404 — domains never accidentally redirect to a placeholder.
- Can teams manage their own rules, or does an operator have to?
- Both models are supported. You can give a client team portal access to manage their own domains and rules, or keep all rule management operator-side and expose only the analytics view. Permissions are per team.
Talk to us about your setup.
Tell us about your domains and team size — we'll get back to you within one business day.