astthorip

Hi Miikka,

Good questions. Here is how this works in practice.

1. Non routable domains

Domains like example.test, local.myproject, or anything that is not publicly reachable are not supported as standalone domains in CookieHub. Our crawler must be able to access the domain in order to scan it and verify the installation.

If the domain is not publicly accessible, it cannot be added as its own domain in the dashboard.

That said, you can still test on non public environments by using test mode.

If you enable test mode on a CookieHub instance that is assigned to a public production domain, you can load that same instance on staging or local environments for testing purposes. This allows you to test banner behavior and consent flows without affecting production data.

2. Separate configuration per environment

Yes, you can create a completely separate CookieHub instance for staging if you prefer full isolation.

In that case:

• Add the staging domain in the dashboard as a separate domain.
• It must be publicly reachable so the crawler can access it.
• It will receive its own domain code.
• It will have its own configuration, scans, and consent logs, fully isolated from production.

This is the cleanest approach if you want strict separation between production and staging data.

3. Recommended workflow

There are two common approaches:

Option A – Single instance with test mode
Use your production instance and enable test mode when working on staging or local. This is simpler and avoids managing multiple instances.

Option B – Separate staging instance
Create a dedicated staging domain in CookieHub. This is better if you want completely separate scans, logs, and configuration.

For local environments that are not publicly accessible, you will need to use the production or staging instance in test mode. There is no way to register a purely local domain that our crawler cannot reach.