FAQ & guides

1) Create a free account — no card needed. 2) Click + New domain. 3) Choose how the domain's DNS is managed: a connected provider (automatic), a one-time CNAME (recommended — works on any registrar), or manual TXT records. 4) Enter the domain and pick the landing-page origin it should serve. Twins Proxy verifies DNS, issues a wildcard certificate (staging validation first, then production), and flips the domain to active only after the edge actually answers with HTTP 200. On automated DNS the whole pipeline usually takes a few minutes, and the wizard shows each step as it completes.

Two things: a domain you control (any registrar) and a landing page URL to serve behind it. That's it — certificates, DNS records, and routing are handled for you.

Yes — e.g. go.example.com can be onboarded as its own masked domain, with its own wildcard certificate covering everything beneath it.

Four providers connect directly and create their records for you: Cloudflare, AWS Route 53, DigitalOcean, and GoDaddy. Any other provider works through one-time CNAME delegation or manual TXT records — the wizard walks you through both, with copy buttons for every record and a check before anything goes live.

You create a single permanent CNAME (_acme-challenge.yourdomain.com pointing at us) once, at any registrar. From then on, certificate issuance and every renewal run completely hands-off — you never touch DNS for that domain again. It's the recommended path when your DNS isn't on Cloudflare.

Open the domain and press Check DNS: you get a per-record verdict — found, missing, or outdated (the record exists but holds stale values; replace them with the ones currently shown). DNS changes can take a while to propagate depending on your provider's TTLs; the check re-runs against public resolvers each time you press it.

Each plan has a rolling 24-hour creation allowance (certificate issuance is a shared resource). If you hit it you'll get a clear message with a retry time — and if you're doing a legitimate bulk migration, contact support for a temporary raise.

Let's Encrypt by default, with ZeroSSL and Google Trust Services selectable per domain where configured. Renewals are automatic and happen well before expiry; if one authority rate-limits, issuance fails over to another automatically. Domains validated by manual TXT records are the one exception: renewals there need fresh records from you, and you'll be emailed with exactly what to change.

Yes — import any certificate + key pair and it's served as-is (imported certificates are never auto-renewed). On Freedom and Unlimited plans you can also export certificate + key whenever you want to take them elsewhere; export requires a fresh two-factor confirmation because it hands out the private key.

The edge is a reverse proxy: it fetches your landing page and serves it under the masked domain's own hostname with a valid certificate for that exact name. No redirect happens, so your primary domain never appears — see masking vs forwarding for the full comparison.

Almost always a rule at your DNS provider. Cloudflare Redirect Rules, Page Rules, and Bulk Redirects run before traffic ever reaches our edge, so a leftover rule on the apex or www silently overrides the masked site. Remove any rule targeting those hostnames. Also make sure the routing records we create stay DNS only (grey cloud) — the orange proxied cloud routes traffic through Cloudflare instead of directly to our edge.

Every domain starts with its apex + www — that is the per-domain allowance on the Free, Basic, and Pro plans. The Freedom plan can add extra exact hostnames (go.yourdomain.com, track.yourdomain.com) up to 5 per domain. Paid plans can also enable wildcard routing to catch every subdomain. The wildcard certificate already covers all of them.

Not by default: new domains send a noindex signal on every response, so search engines never treat them as duplicate content of your primary site. It's a per-domain toggle if you ever want one indexed.

Give the proxy a custom User-Agent or a secret identity header in the site's Origin firewall allowlisting panel, then create a matching allow rule at your origin's firewall. The panel generates the secret and a ready-made Cloudflare WAF expression to paste.

A serving node is your own VM running the edge — your IP address, your bandwidth, no traffic metering, and an effectively unlimited domain count on the Freedom plan. The control plane still automates DNS, certificates, and routing; the node just serves. Freedom includes 2 nodes; add more at any time for $7/month each.

Any Linux VM with ports 80/443 free: create the node in the dashboard, run the one-line installer it gives you, and enrollment (including an automatic ownership check of the IP) completes in about a minute. Docker is installed automatically if missing, and the agent binary's checksum is verified before it runs.

It keeps serving from its last-applied configuration for 24 hours. Past that it fail-closes (stops serving) and resumes automatically as soon as contact is restored — a stale node serving forever would be worse than a dark one.

Use this when repurposing a VM that previously ran the node agent — a decommissioned node, a rebuilt control plane, or a server you're handing to a different workspace. Run as root on the node:

systemctl disable --now twinsproxy-node-agent
rm -f /etc/systemd/system/twinsproxy-node-agent.service
systemctl daemon-reload
rm -f /usr/local/bin/twinsproxy-node-agent
docker rm -f twinsproxy-caddy
rm -rf /var/lib/twinsproxy /var/log/twinsproxy /opt/twinsproxy

This removes the agent, its serving container, the old node credential and lease state, and — importantly — every certificate and private key the old enrollment delivered. The server is now a blank Docker host. To use it again: create the node in the dashboard (Nodes page, or Admin → Platform serving nodes), run the one-line enrollment command it shows, and watch it come up with:

journalctl -u twinsproxy-node-agent -f

You should see enroll → verify-ip → heartbeat within about a minute, and the node flips to verified in the dashboard. Enrollment always mints a fresh credential, so nothing from the old life carries over.

The node installer installs Docker automatically when it's missing, so normally you can skip this. To install it yourself on any mainstream Linux (Debian, Ubuntu, RHEL-family):

curl -fsSL https://get.docker.com | sh
systemctl enable --now docker
docker run --rm hello-world

If the last command prints "Hello from Docker!", you're done. On distros without systemd, start the daemon with service docker start instead.

Creating a node asks for the server's public IPv4 (required) and optionally its IPv6. From a shell on the server:

curl -4 -s https://ifconfig.me   # public IPv4
curl -6 -s https://ifconfig.me   # public IPv6 (an error = no public IPv6, which is fine)

To see what's configured on the interfaces directly:

ip -4 addr show scope global
ip -6 addr show scope global

Two things to watch: on many cloud VPSes the interface shows a private address (10.x / 172.16–31.x / 192.168.x) while the public IP is NATed — always use the public one, which is what curl -4 ifconfig.me and your provider's console report. And IPv6 is genuinely optional: the platform treats it as best-effort and never requires it.

The node's edge needs both ports. Check for existing listeners:

ss -tlnp | grep -E ':(80|443)\s'

No output means the ports are free. If nginx or Apache holds them and you don't need them on this server:

systemctl disable --now nginx apache2 2>/dev/null

The installer also preflights this: a conflicting Docker container publishing 80/443 is a hard stop, and any other listener is a warning you can override deliberately.

Inbound, the node needs 80/tcp and 443/tcp from anywhere (plus your own SSH). With ufw:

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

On cloud providers, the same rules usually live in a security group / cloud firewall in the provider console — check both if traffic doesn't arrive. Outbound, the agent only makes HTTPS requests to the platform; no inbound management port is ever opened.

Free: 1 domain, 10 GB/mo, single user. Basic $15: 10 domains, 150 GB, 2 team seats. Pro $39: 25 domains, 500 GB, 3 team seats. Freedom $25: your own node, no practical domain ceiling, 4 team seats. Add-ons stack on any paid plan: +10 domains ($15/mo), +100 GB ($8/mo), extra node ($7/mo), dedicated edge IP ($25/mo). Full details on the pricing section.

Yes — on any paid plan, from the Team page. Basic includes 2 seats, Pro 3, Freedom 4 (including you). Invited members get full working access — domains, DNS connections, nodes, API keys, certificates — while billing, member management, and workspace deletion stay with the owner. Invitations are emailed links valid for 12 hours, and a pending invitation reserves a seat. Someone who already has a Twins Proxy account can accept too: their account joins your workspace and they switch between workspaces from the menu in the top bar.

Upgrades apply the moment payment settles. Downgrades first check that your domain, hostname, and node counts fit the target plan — if not, you're told exactly what to reduce. Cancelling (or downgrading to free) is self-serve via the Stripe billing portal; cards, invoices, and receipts live there too. Discount codes are entered at checkout.

Nothing dramatic at first: Stripe retries the card and emails you (dunning), and your service continues during that window. Only when the subscription is finally past saving does the workspace drop to the free plan — and over-limit domains get a grace period before anything is suspended.

Passkey (WebAuthn) sign-in or password + TOTP two-factor with recovery codes; sensitive actions require a fresh verification; the Sessions panel shows and revokes every signed-in device. API access uses scoped, least-privilege keys with optional expiry, and every change in your workspace is in the audit trail.

Encrypted at rest with AES-256. They're used to write the records you've authorized and are never exported — not even in your own data export.

Settings → Export downloads a zip of your workspace (profile, domains, sites, usage, audit history — never your secrets). Deletion is self-serve for the workspace owner: service stops immediately, and data is purged after a 30-day grace window during which you can cancel and restore the account. Domains removed at deletion time are not restored — the confirmation screen spells all of this out.

The public abuse desk takes reports from anyone, with optional evidence attachments. Every served domain is also screened continuously, and reports feed a human review queue.