Security posture

Written for the person whose job is finding the gap.It names the ones we have.

What runs where, what crosses between the two regions and in which direction, who is allowed to change the fleet, and which assurances do not exist. Forward this page. It is meant to be read by someone who did not choose the product and has no reason to be generous about it.

Execution: your hardware
Audit reports: none held
Roles: admin · operator · viewer
Licence check: fails closed

01Posture

Current posture

What is not in place

First, because you would find it anyway, and because a page that states its own limits is more use to you than one that arranges its words around them.

Not held

None
No third-party audit or certification
VeilBrowser has not been audited against SOC 2, ISO 27001 or any comparable framework, and holds no report, certificate or attestation. Some vendors in this category do publish one. If that is a hard requirement in your process, it is a genuine reason to rule us out today, and it is better established on the first call than the fifth.
None
No published data-protection position
There is no data-processing agreement, sub-processor register or privacy framework statement published here, and nothing on this site should be read as standing in for one. If your review needs those documents, that is a conversation rather than a download.
Never claimed
Not a claim that data stays on your network
Browsers, sessions and browsing traffic run on your infrastructure. Organisation records, plan state, profile metadata and licence verification live in ours. Connections cross between the two, and they are enumerated below rather than summarised away.
None
No bug bounty and no published disclosure window
Reports reach the engineers who wrote the code, and nothing here promises a response time or a payout, because neither is in place.

What exists instead

Execution on hardware you provision, so browser processes and everything they write to disk stay inside your perimeter
A boundary you can read: every connection that crosses it, its direction, and what it carries
An edge that closes connections which did not arrive the way you configured, without answering them
Three roles enforced in the request handler, and an audited record with attribution for every mutating action
A licence check that refuses a launch it cannot verify rather than allowing it
Published defaults: every interval, timeout and retry count on this site is the shipped one

Nothing on this page needs a call to verify. The installer, the defaults and the edge configuration are public documentation.

Edge security docs

02Boundary

The trust boundary

Two regions, and what each one holds

Execution and the software that operates it sit on infrastructure you provision. Commerce, identity and profile records sit in ours. Browser traffic is not one of the connections between them: it leaves your region through the proxies you configure and goes straight to the target.

1Licence and plan verificationoutbound
2Encrypted profile bundlesinbound
3Browser build downloadsinbound

Fig. 01Three connections cross the boundary in the drawing. Browser traffic is not one of them; it leaves through the proxies you configure.

On your infrastructure

Browser processes, their profile directories, and everything a session writes to disk
The fleet manager and its database, including every operation record, log and fleet snapshot it writes
TLS private keys and the certificate the origin serves
Egress: the proxy each profile uses, and therefore every request that reaches a target site
Console accounts, sessions and roles for the self-hosted cluster

In VeilBrowser's infrastructure

Organisation and user records for the platform account
Plan and subscription state
Profile metadata: the device description, and which organisation holds it
Licence verification, and a session start reported so a launch can be counted against the plan

The asymmetry is deliberate and it is the part worth arguing about internally: the material a review usually cares about most, which is what a browser does and what it stores, is on your side of the line. The commercial record of the account is on ours.

03Crossings

For the reviewer

Every connection across the boundary, and why

Five rows. Four of them cross. The fifth is the one a review usually asks about first, and it does not.

Connections between your infrastructure and VeilBrowser's, with direction, payload, purpose and where each terminates
Connection	Direction	What it carries	Why	Terminates at
Licence and plan check	Outbound	The organisation key, a machine identifier, the profile or device specification, and the requested operating system and Chrome major	Authorise the launch against the plan's concurrency limit	VeilBrowser API
Usage metering	Outbound	A session start for the profile that launched	Count the session against the plan	VeilBrowser API
Profile bundle	Inbound	The encrypted bundle for a profile the worker has not run before	Materialise the profile on the worker that will run it	The worker's install volume
Browser build	Inbound	The Chrome build pinned to the profile	Fix the device signature in the build rather than in a per-page script	The worker
Browsing traffic	Does not cross	Requests to target sites, cookies, storage and page content	Not applicable: it is never routed through VeilBrowser	Your proxy, then the target site

Four things worth knowing about those rows

01
The machine identifier defaults to the host's own hostname when the caller does not supply one, so it is worth setting deliberately if a hostname is itself sensitive in your environment.
02
The licence check fails closed. If it returns a denial, or cannot complete at all, the launch is refused. There is no local grace mode that lets a browser start while verification is unavailable, which is the behaviour to plan for if your workers sit behind an egress policy.
03
The check runs when a launch is requested. It is a gate in front of starting a browser rather than a heartbeat behind one.
04
Operation records, their logs and fleet snapshots are written to the self-hosted manager's own database and are not sent to us.

04Network edge

The network edge

What the origin answers, and what it refuses

Once a hostname is configured, the edge stops behaving like an open IP. It serves the hostnames you named and closes everything else with HTTP 444, which is the connection being dropped without a response rather than a page a scanner can fingerprint.

Fig. 02HTTP 444 closes the connection without answering, which is a different signal to a scanner than a 403 page.

What arrives with a hostname

Cloudflare origin lock: The edge reads the real connecting peer and refuses anything that is not a current Cloudflare range or loopback. Cloudflare's published ranges are fetched when the configuration is rendered, with a bundled fallback list in the image, so a render never depends on reaching the network.
Decoy certificate: A handshake for a hostname the cluster does not serve is answered with a self-signed certificate carrying a bogus common name and no real subject alternative name, then closed. An address-space scanner records the decoy, so your real domain never appears in its results.
Optional mutual TLS: With Cloudflare and Full, the origin can require a client certificate from Cloudflare's origin-pull authority, so only Cloudflare completes the handshake. Off unless you turn it on.
No version disclosure: Server tokens are off, so neither a response header nor an error page advertises what is running or which version of it.

TLS termination, three modes

Behind Cloudflare: Cloudflare terminates TLS with the browser. Flexible leaves the origin on port 80; Full serves HTTPS on 443 with either a self-signed origin certificate or one issued through the Cloudflare API using a one-time token that is used once and not stored.
Your own certificate: A PEM certificate and key you supply. The origin serves HTTPS on 443 and redirects 80 to it. Use this when the certificate already exists, with or without a proxy in front.
Let's Encrypt: Issued and renewed inside the edge process over the HTTP-01 challenge, with no cron job and no additional service. It needs DNS pointing straight at the origin, so it is not the mode to use behind a proxy that intercepts port 80.

Where none of this applies

An evaluation install with no hostname is deliberately reachable over plain HTTP on its IP address, so a cluster can be tried before DNS exists. None of the protections above are active in that state, and it is not a state to leave running. Configuring a hostname is what switches them on.

The origin lock lives inside the edge. The documentation also carries ufw and nftables rules for restricting ports 80 and 443 to Cloudflare's ranges at the operating-system level, so unwanted traffic never reaches the process at all.

Every directive behind these behaviours is in the self-hosting documentation, including the ones you would want to check rather than take on trust.

Edge security and TLS

05Access control

Identity and change control

Who can change the fleet, and what that leaves behind

Three roles, ranked. The check runs in the request handler, so it holds for anything talking to the API and not only for the console. Every mutating action opens a record before it starts and closes with a status, an exit code and the account that started it.

The three roles

admin: Everything an operator can do, plus applying a rendered configuration, managing users and managing TLS. Applying a config is deliberately not delegated.
operator: Change cluster and fleet settings, stop, start and update workers, and preview a rendered configuration without being able to put it into service.
viewer: Read the fleet, the operations and the configuration. No mutating action of any kind.

Accounts

The administrator account is created during setup, so no image ships with a default password
Roles are ranked, so a permission granted to a viewer is available to an operator and an admin as well
The role check is a server-side gate on the route, not a hidden button in the interface

Licensing fails closed

A launch is authorised against the plan before a browser starts. A denial refuses it, and so does a check that cannot complete. There is no fallback that allows a session while verification is unavailable, which is the behaviour to design your egress policy around rather than discover during an incident.

Records, logs and snapshots stay in the manager's own database on your host. Reading them needs no cooperation from us, and neither does keeping them.

The operating detail behind each of these, including the intervals and the rollback behaviour, is on the enterprise page rather than repeated here.

How it operates Self-hosting security

06Review answers

Questionnaire

The questions a review sends first

Answered here so the first call is about your deployment rather than about a spreadsheet. Where the answer is no, it says no.

01Where does our data live?Browser sessions and everything they write to disk stay on your hosts, along with the manager's database and its audit records. Organisation records, plan state, profile metadata and licence verification live in VeilBrowser's infrastructure.

The five rows in the crossings table above are the complete list of connections between the two regions, with what each one carries. Browsing traffic is not among them: it leaves through your proxies to the target site.

02Do you hold SOC 2 or ISO 27001?No. There is no audit report, certificate or attestation, and nothing on this site should be read as implying one.

What can be checked instead is the architecture: execution on hardware you provision, an enumerated boundary, published defaults, and roles enforced server-side. If a report is a hard gate in your process, that is a real disqualification rather than something to work around.

03What happens if we cannot reach you?New launches are refused. The licence check fails closed, so a browser is not started while verification is unavailable.

The gate runs when a launch is requested, so it is the start of a session that depends on the check rather than its continuation. If your workers sit behind a strict egress policy, reaching the licensing endpoint is the dependency to plan for.

04Who can change what the edge serves?Admins only. An operator can render and diff a candidate configuration but cannot put it into service, and a viewer can read.

The check is in the request handler, so a credential with a viewer role can do no more against the API than a viewer can do in the console. Every applied change is an operation record naming the account that applied it.

05Can we restrict who reaches the origin?Yes, at two levels: the edge refuses any peer that is not Cloudflare or loopback once the origin lock is on, and a host firewall can stop that traffic before it reaches the process.

The documented rules for ufw and nftables restrict ports 80 and 443 to Cloudflare's published ranges. Those ranges change occasionally, so refreshing them is an operational task on your side. The edge refreshes its own copy whenever the configuration is rendered.

06How do we report something?Through the contact form, marked as a security report. It reaches the engineers who wrote the code rather than a queue.

There is no bug bounty programme and no published disclosure policy, so nothing here commits to a response window. If that matters to your process, raise it on the first call.

A question that is not answered above is one we would rather take before an evaluation than during it.

Contact sales Get started

Send this page to whoever owns the review.

It is written to survive being read out of context, by someone who is looking for the reason to say no. If they find one that is not already on the page, we would like to hear it.