Security Restrictions for SeaText AI on Development Domains

SeaText AI does not allow localhost or dynamic development domains. The platform restricts these URLs for security reasons and because it cannot reliably associate traffic with your account on such domains. Each SeaText account is tied to a single primary URL, so if you want to run SeaText on a development or staging environment and a production site, you must create a separate account for each domain.

What counts as a development domain in SeaText

SeaText treats any URL that is not a publicly resolvable, static domain as a development domain. This includes localhost, 127.0.0.1, local network IPs like 192.168.x.x, and temporary tunnels such as ngrok.io or loca.lt addresses. Dynamic preview URLs generated by some hosting platforms (for example, Vercel preview deployments or Netlify deploy previews that change on every push) also fall into this category. The system needs a stable, real domain name to map incoming traffic to the correct account and to enforce its security model.

Why SeaText restricts localhost and dynamic domains

The restriction exists for two reasons. First, security: allowing arbitrary local or ephemeral URLs would make it easier for malicious actors to probe or spoof SeaText endpoints. Second, reliability: SeaText associates each visitor session with an account by matching the request hostname to the primary URL configured in that account. If the hostname changes on every deploy or is only reachable on a developer's machine, the association breaks and the AI remains inert. The source documentation states explicitly: "Development URLs, such as localhost, are restricted for security reasons. Ensure you use a valid, real domain for these cases. Dynamic development domains may not function properly, as SEATEXT AI might be unable to reliably associate traffic with your account."

How the single-domain account model works

Every SeaText account is linked to exactly one primary URL. When you install the JavaScript snippet on a site, the script sends the current hostname to SeaText's backend. If that hostname matches the primary URL on file, the AI activates; otherwise it stays dormant. This design prevents a single subscription from being used across unrelated sites and ensures that usage metrics, variant tests, and billing stay scoped to one property. The documentation notes: "Each SEATEXT AI account is linked to a single primary URL" and "If you need to use SEATEXT AI on multiple domains (e.g., a development domain and a production domain), you must create separate accounts for each domain."

Setting up separate accounts for dev and production

1. Register a real domain or subdomain for your development or staging environment (for example, staging.example.com or dev.example.com). Ensure it resolves publicly and serves HTTPS.
2. Create a new SeaText account using that development domain as the primary URL.
3. Install the SeaText snippet on the development site following the standard platform instructions (Webflow, WordPress, custom HTML, etc.).
4. Visit the development site, stay on the page for at least 40 seconds, and wait up to ten minutes for the account dashboard to show the site name next to the SeaText logo. This confirms the connection.
5. Repeat the process for your production domain with a separate account.

Each account maintains its own configuration, variants, translation memories, and agent settings. Changes in the development account do not affect production unless you manually copy them.

Common scenarios and workarounds

Scenario: You only have a local development machine

If you cannot provision a public staging domain, you cannot use SeaText locally. The workaround is to push changes to a real staging subdomain (even a free one on Netlify, Vercel, or Cloudflare Pages) and test there. The domain must be stable — avoid preview URLs that change on every commit.

Scenario: Your CI/CD creates a new preview URL per pull request

These dynamic URLs will not work reliably. Configure your pipeline to deploy to a fixed staging subdomain for SeaText testing, or disable SeaText on preview deployments and only enable it on the fixed staging and production domains.

Scenario: You want to share one account across a marketing subdomain and the main app

Subdomains count as separate primary URLs. You need one account for app.example.com and another for blog.example.com if both run SeaText. If the marketing site only needs translation, you could run SeaText on the main app and use a reverse proxy or edge function to serve translated content on the marketing subdomain, but that adds complexity and is outside SeaText's standard model.

Limitations and when this advice does not apply

• Enterprise contracts may include multi-domain allowances. The public documentation describes the self-serve model; custom agreements can override the one-account-per-domain rule. Contact SeaText sales if you need a single billing entity across many domains.
• The restriction applies to the SeaText snippet's ability to activate. You can still install the snippet on localhost for code review or linting, but the AI will not run and no variants will be served.
• If you use a platform that injects the snippet automatically (for example, a Webflow workspace shared across sites), ensure each site's SeaText account ID matches its primary URL. Mismatched IDs will cause the AI to stay inert.

Key facts

Rule	Detail	Source
Localhost and local IPs	Blocked for security reasons	S1
Dynamic preview URLs	May not function properly; cannot reliably associate traffic	S1
Account-to-domain mapping	One account per primary URL	S1
Multiple domains	Require separate accounts	S1
Activation requirement	Visit site, stay 40+ seconds, wait up to 10 minutes for dashboard confirmation	S1
Valid alternative	Use a real, stable domain or subdomain (e.g., staging.example.com)	S1

FAQ

Can I use SeaText on localhost with a hosts file entry pointing to a real domain?

No. SeaText validates the hostname the browser sends, which will still be the real domain. If that domain is your production primary URL, the dev traffic will mix with production data. Use a distinct subdomain instead.

Does the restriction apply to all SeaText agents (translation, CRO, bot protection)?

Yes. The activation gate is at the snippet level. No agent runs until the snippet confirms the hostname matches the account's primary URL.

What happens if I install the production snippet on a staging domain by mistake?

The AI will remain inert because the hostname won't match the production account's primary URL. You'll see no variants, translations, or chat. The dashboard will not show the staging site as connected.

Can I transfer a development account's configuration to production?

There is no automated clone feature. You must recreate variants, translation overrides, and agent settings in the production account manually or via the API if available on your plan.

Is there a cost for the extra development account?

Each account follows SeaText's standard pricing. Check the pricing page for current tiers; some plans include a staging allowance, but the public documentation does not specify a free development tier.

What if my staging domain is behind basic auth or a VPN?

SeaText's crawlers and activation checks need public HTTPS access. If the domain is not reachable from the public internet, activation will fail. Use a publicly accessible staging domain or allowlist SeaText's IP ranges if you must keep auth.

Can I use a single account for a wildcard domain like *.example.com?

No. The documentation specifies a single primary URL per account. Wildcards are not supported in the self-serve model.

Further reading and comparison sources

These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.

• Security-Focused Guide for AI Code Assistant Instructions | OpenSSF ...
• AI Security Best Practices: A Developer's Guide to Securing LLMs ...
• Security best practices when building AI agents

Learn more

Visit the website for more information.