BYOC Architecture

Audience: Enterprise security architects, procurement reviewers, DPOs evaluating HailBytes for purchase.

Purpose: Make the structural risk-reduction of HailBytes’ Bring-Your-Own-Cloud (BYOC) deployment model legible. The reason most security questions are answered the way they are throughout this trust package is that the data plane runs entirely inside the customer’s cloud account.

1. The deployment model in one sentence

Both HailBytes ASM and HailBytes SAT are delivered as customer-deployed virtual machine images (AWS Marketplace AMI, Azure Marketplace VHD) that run end-to-end inside the customer’s own cloud account. HailBytes operates no shared data plane, no multi-tenant database, and no central scan-result store.

2. What runs where

Component	Runs in customer tenant	Operated by HailBytes
ASM web app (Django + Gunicorn + Uvicorn)	Yes	No
ASM scanner workers (Celery + ~30 security tools)	Yes	No
ASM datastore (PostgreSQL, Redis, PgBouncer; current LTS versions pinned per release)	Yes	No
SAT admin server	Yes	No
SAT phishing server	Yes	No
SAT datastore (PostgreSQL; current LTS pinned per release)	Yes	No
SAT background workers (campaign send, IMAP reply tracking)	Yes	No
Customer-scanned asset data	Yes (only here)	No
Customer employee target lists (SAT)	Yes (only here)	No
Phishing-simulation results, audit logs	Yes (only here)	No
Container registry (`ghcr.io/hailbytes/*`)	—	Yes (read-only public pull)
Marketplace listing distribution (AWS + Azure)	—	Yes
Marketing site, support hub, billing back-office	—	Yes
Per-release supply-chain artifacts (SBOMs, SARIFs, Cosign attestations)	—	Yes (public, signed)

The container registry and marketplace distribution are pull-based and unauthenticated for the public images; they do not phone home and do not receive any telemetry from running customer instances.

3. Data-flow boundary

The boundary that matters for LGPD, GDPR, and most enterprise data-handling reviews is between the customer’s cloud account and the public internet. HailBytes is on the public-internet side of that boundary.

Data crossing the boundary, outbound from customer tenant:

Container image pulls from ghcr.io/hailbytes/* on initial install and on each customer-initiated update. No authentication header carries identifying information beyond the public Docker pull semantics.
Customer-configured outbound integrations (Slack, Discord, Microsoft Teams, Splunk HEC, Sentinel, PagerDuty, ServiceNow, Jira, customer-owned SMTP relay, customer-owned LLM endpoint). These targets are configured by the customer, point at customer-owned infrastructure or customer-chosen third parties, and do not route through HailBytes.
Optional outbound to third-party intelligence sources the customer enables (Shodan, Censys, GreyNoise, VirusTotal, AbuseIPDB, HIBP, OpenAI, Anthropic). These are off by default; when enabled, the customer brings the API key and HailBytes never sees the key or the responses.

Data crossing the boundary, inbound to customer tenant:

Container image layers (signed, verifiable — see §5).
Marketplace VM image updates (when customer initiates).

Data that never crosses the boundary in either direction:

Scan results, vulnerability findings, screenshot evidence (ASM).
Employee email lists, target metadata, campaign results, submission data (SAT).
Audit logs, RBAC state, user accounts, API keys.

There is no telemetry beacon, no usage-statistics ping, no license check-in. The product runs offline-capable once installed. This is verifiable by network-egress filtering: a customer can deploy with egress restricted to their configured integrations and the public container registry, and the product continues to function.

4. Architecture diagram

BYOC data boundary diagram: customer-cloud-resident ASM and SAT VMs on the left; HailBytes-operated registry, Marketplaces, marketing site, and Support Hub on the upper right; customer-elected integrations such as Slack, SIEM, and threat-intelligence sources on the lower right. Arrows are outbound from the customer tenant only; no inbound from HailBytes.

The diagram source is at hugo-site/static/images/diagrams/byoc-data-boundary.svg, following the same SVG convention as the existing /images/diagrams/ set (defense-in-depth.svg, asm-scan-pipeline.svg, sat-campaign-lifecycle.svg).

What the diagram shows, in words:

Customer cloud account (left, large box): the ASM VM and SAT VM run here in the customer’s chosen AWS or Azure region. Scan results, employee target lists, audit logs, RBAC state — all stored on these VMs. The customer controls KMS keys, IAM, VPC, egress rules, and backup cadence.
HailBytes-operated (upper-right): the public container registry, Marketplace listings, marketing site, the HailBytes-built Support Hub on Cloudflare, and build VMs. No customer-tenant data lives here.
Customer-elected integrations (lower-right): Slack, SIEM, threat-intelligence sources, LLM APIs, SMTP relay. The customer brings credentials and chooses destinations; these are not HailBytes subprocessors.
Arrows: outbound-only from the customer tenant. Image pulls into the tenant happen only when the customer initiates an update. There is no inbound channel from HailBytes into a running customer deployment.

5. The controller/processor claim

Under LGPD (Lei Geral de Proteção de Dados, Brazil) and GDPR (EU/EEA), HailBytes is neither a controller nor a processor of the customer’s scanned-asset data, employee target lists, or phishing-simulation results. The structural reason: HailBytes never receives, stores, transmits, or processes this data. It exists exclusively on infrastructure the customer provisions, owns, and controls.

HailBytes is a processor for the limited operational data it does handle: support-portal contents the customer submits, marketing-site form submissions, and billing records (necessarily, since billing runs through Marketplace settlement). This is governed by HailBytes’ DPA, available alongside this trust package.

The legal framing here is conservative; some advisors would argue HailBytes is also not a processor for support-portal contents in the technical sense, but the trust package treats it as such because it’s the safer default for customers.

6. Operational consequences customers should know

Patches and upgrades are customer-initiated. HailBytes ships images; customers decide when to pull. This means the customer is responsible for staying current on security releases. See bcp-dr-plan.md for the customer-side patching playbook.
HailBytes cannot remotely fix a broken customer deployment. Support is advisory; the customer’s operators execute changes. This is a deliberate trade-off in favor of the data-residency posture.
Backups are the customer’s job. PostgreSQL volumes live in the customer’s account; the customer chooses snapshot cadence and retention. HailBytes documents the recommended baseline (daily snapshots, 30-day retention, tested restore quarterly) in the hardening guide.
Customer-side compromises do not propagate to HailBytes or to other customers. Single-tenant deployment is structurally isolating.

7. Verifying this is true

A customer who wants to verify the claims above can:

Deploy ASM or SAT to a fresh cloud account with no egress rules configured.
Inspect outbound network traffic during a representative workload (a scan run, a phishing campaign).
Confirm that the only outbound connections are container-registry pulls and integrations the customer themselves configured.

HailBytes offers to walk a customer’s security team through this verification under NDA — see references-and-evidence.md.

Cross-references: security-evidence-package.md describes the per-release artifacts that prove what code is running inside the customer tenant; lgpd-compliance.md extends the controller/processor framing into Brazilian regulatory specifics; bcp-dr-plan.md covers the customer-side resilience implications of customer-owned deployment.