Self-Hosting (On-Prem)
Run the entire Tripwires product inside your own environment — admin UI, API, honeypot sink, and data store — with no dependency on our cloud account. This section walks through the architecture, container images, deploy paths, configuration, Active Directory / LDAP, and verification.
The Docker Compose and single-EC2 deployment paths are verified end-to-end.
What "self-hosted" means
The same core/ business logic that powers the multi-tenant SaaS (as AWS
Lambdas) also runs as a single control server binary
wired to on-prem adapters — Postgres, the local filesystem, SMTP, and an in-process event
bus. One codebase, two tenancy models: the SaaS gates features by subscription tier; a
self-hosted install is single-tenant and gates features with
per-installation toggles on the System Setup screen.
Control server
One Go binary: admin UI + API + the detection ingest endpoint, with the frontend baked in.
Sink
The Rust honeytoken-sink — listens on the honeypot ports and captures intrusions.
Postgres
The data store — a container, or your own managed Postgres / RDS.
Directory (optional)
Your own Active Directory / LDAP for single sign-on.
Architecture
Everything lives in your environment. Detections travel from the sink to the control
server as authenticated HTTP POSTs (X-Ingest-Token) — never through our cloud.
- The control server serves the admin UI on the same origin as the API — a single TLS endpoint.
- The sink answers on the honeypot ports like the real service, captures the credential or connection, and POSTs the detection inward.
- TLS is terminated by an ALB + ACM on AWS, or by your own reverse proxy. (Public ACM certs can't be installed on raw EC2 — they need an ALB/NLB/CloudFront.)
Admin console
Operators get an admin console for the whole deployment — user management, a cross-tenant tripwire inventory, an audit trail, system health, and support.