How Infraveil
Is Built
This page explains exactly how Infraveil works, what protects your backend, and what we can and can't prove. The dashboard, the launcher, and the agent are kept separate from your code. The launcher runs on your server, the agent keeps your services running, and a config file describes your app — so Node, Python, Go, Rust, Java, or any command-line service runs the same way through one dashboard.
Don't trust us.
Check our work.
A log can be edited. A dashboard can show anything. So we built our security so you can confirm it yourself. The keys on this page are real and live, and every claim below ends in a step you can run from your own terminal — without taking our word for it.
Our public signing key
This is the live Ed25519 public key we use to sign every Infraveil release and every sealed data export. The key is public on purpose: anyone holding it can check our signatures, and you don't need any secret from us to do it. We publish it at an open endpoint so you can verify a signature anytime, without asking us first.
d04d47f65da228425d873e7a4d1b8742bbfdfee0a116842031abe5cce6dd1935
d424ae2f080160ad09c2c192- 1Take the signed file (a release manifest or a data export) and remove its signature block.
- 2Serialize the rest as sorted-key, compact, UTF-8 JSON. Its SHA-256 must match the stated
content_sha256— that confirms the contents weren't changed. - 3Check the Ed25519 signature over those bytes against the key above — that confirms it really came from us. Anyone can do this; no secret required.
We also attach an HMAC signature, and we'll say plainly what it is: it uses a shared secret, so only you and Infraveil can check it — not an outside party. We label what you can prove and what you can't, every time.
The code we ship is the code we published
Each Infraveil release comes with a list of exact file hashes, signed with the Ed25519 key above. Download the release and the key, and you can confirm the files are genuine and unchanged. Anyone can check this; no secret required.
Where this stops: this proves the published files are genuine. It does not, on its own, prove the server is running exactly those files — a server can report whatever hash it likes. Proving that needs reproducible builds, an outside transparency log, and remote attestation. We don't have those yet; they're listed under "the limits of this page" below.
The code that runs on your server is code you can read
The launcher and agent are the only Infraveil software that runs on your server, and they ship as plain, readable source — not obfuscated, not compiled away. You can open the files and read exactly what they do. You don't get the source for our hosted dashboard; you hold that to account with the signature checks and the limits described above. But the software with real access to your machine, you can inspect directly.
You can't read the source for our hosted dashboard. You hold it accountable the way you'd check any closed software: verify its signed releases against our published key, test how it behaves, and weigh the limits listed above.
The launcher and agent are not obfuscated and not compiled away. Open the files on your own server and read exactly what they do — how they log in, what they collect, what they send. Then watch their outbound network traffic with your own tools and confirm the code and the traffic match.
To be clear: this is source you can read on your own server — not yet a public repository with version history or reproducible builds (those are on the roadmap below). But the code running on your machine is code you can open today.
Traffic Log — see what your server sends us
Most agents give you no way to see what they send back. We show every request the launcher and agent make to us, right in your dashboard — the method, the path, a hash of the body, and the signature that authorized it. Each request is signed and protected against replay, so neither side can slip in a forged one.
What this does and doesn't prove: a dashboard we draw can't prove that no other connection exists. The real check is on your side. The launcher and agent are readable source on your own server, so you can read exactly what they do, and you can record all of their outbound traffic with your own network tools. Don't take the dashboard's word for it — capture the traffic yourself. That check never runs through us.
HMAC-SHA256 over the method, path, timestamp, query, and a hash of the body. Change one byte and the check fails. (This uses a shared secret, so it's verifiable between you and us, not to outside parties — see the limits below.)
A single-use nonce and a tight time window, checked on our server. A captured request can't be sent a second time.
The agent is readable source on your server. Read what it sends and record its outbound traffic with your own tools — the check doesn't run through us.
Your server keeps the full record. We hold only a checkpoint.
The agent writes down what it does in a tamper-evident, append-only log on your own server, where each entry locks in the one before it. We only receive the latest checkpoint — a single hash — inside the signed heartbeat. So the full record stays on your machine, and neither side can quietly rewrite history: change any past entry on your disk and the chain breaks and stops matching the checkpoint we hold; have us claim a different checkpoint and it won't match your log. You can re-check your log against our checkpoint anytime. (To be exact: this proves your local log is intact and ends where we say it does. The checkpoint comes from us, so an outside-timestamped checkpoint or public transparency log — on our roadmap — is what would let an outside party prove it too.)
Don't take our word for the chain either. The checker is plain Python, standard library only — read it, then run it against your own log: python verify-ledger.py agent_audit_<id>.jsonl --head <checkpoint from your dashboard>. It re-hashes every entry, checks the chain, and confirms your log matches the checkpoint we hold — entirely on your machine, trusting nothing of ours.
The layers that protect you
Software with this much access to your production servers has to be held to a high bar. We treat its security as ongoing work, not a one-time launch task. Every item below is in the code we ship. The ones on your server you can confirm yourself by reading the agent. The ones on our side you can't inspect yet — that gap, and how we plan to close it, is in the limits section below.
Each app package is encrypted
App packages are encrypted with AES-GCM using a key unique to each agent. The agent checks the signature before decrypting, and checks the package hash before running a single line of code.
Signed, replay-proof traffic
Every launcher and agent request is signed (HMAC) with a single-use nonce and a 5-minute time window. Forged or repeated requests are rejected before they're processed.
Extra checks for risky actions
Sensitive actions require a second factor: a TOTP code, a separate action PIN, or a hardware key (WebAuthn / Windows Hello). Secrets are compared in a way that doesn't leak through timing.
Outbound requests are fenced in
Any outbound URL you configure is forced to HTTPS and blocked from internal addresses (loopback, link-local, cloud-metadata, and private ranges) — so it can't be tricked into reaching into a private network.
No room for command injection
Commands run without a shell, with arguments split safely and shell operators rejected. Package extraction refuses absolute paths, directory traversal, and symlinks.
Outside binaries are checksum-verified
When the agent downloads a managed gateway binary, it checks it against the publisher's signed checksums before running it. A mismatch means it won't run.
Built-in abuse and rate limits
Abuse scoring, rate limits, trap routes for scanners, and automatic IP blocking run in front of every request. They use a bounded amount of memory, so the defenses can't themselves become an outage.
Readable on your own server
The launcher and agent aren't obfuscated — they run as source you can open and read. Every claim on this page about what runs on your server is something you can confirm in that code.
Exports you can verify
When you export your data, it comes with a content hash, an HMAC, an Ed25519 signature, and the exact steps to check them — so you can confirm it's genuine without trusting how it reached you.
If our dashboard goes down,
your services stay up.
Many agents stop working when they can't reach their service. Ours keeps going. If it can't reach us, it keeps your services running from the last good copy it saved (encrypted on disk), logs the outage once instead of every cycle, waits, and resyncs as soon as we're back. It also tells apart three different situations — we're unreachable, your access was revoked, or your billing is locked — and handles each one correctly.
Keep serving from the encrypted last-good copy, wait, and resync automatically when we're back.
If access is actually revoked, the supervisor shuts down cleanly rather than running orphaned.
By default, continuity mode keeps your current services serving and only pauses new deploys — a billing dispute won't take your production down.
What a code package has to pass before it runs
A package doesn't run just because it arrived. It has to clear four checks first — decrypted, signature-checked, and matched against our own record — before a single line runs. (That record is ours, not an outside party's: this catches a stale or swapped package on your machine, not a compromise of our dashboard itself — see the limits below.)
1 · Decrypt
AES-GCM authenticated decryption with a per-agent key. A tampered package fails the auth tag here.
2 · Check the signature
The package hash carries an Ed25519 signature, checked against a key written into the agent's own readable source — so you can see exactly which key your agent trusts — plus an HMAC tied to the agent's key. Wrong key, no run.
3 · Match our record
The local hash is re-checked against our record over a separate request — so a stale or swapped package is caught.
4 · Execute
Only now does it run — extracted with traversal, symlink, and drive-letter protections, commands run with no shell.
Stop a compromised Infraveil from running code on your server
The worst case for any vendor running inside your production is that the vendor itself gets hacked. So we built a switch and gave you the only key. Turn on release approval and your agents run only the releases you signed yourself — with a key we never see and can't forge.
1 · Your key, offline
Generate an approval keypair on a machine we never touch. Register the public key; keep the private key offline. We only ever store the public half.
2 · Sign each release
To approve a release, sign its hash offline and submit the signature. No signature, no approval.
3 · Agent enforces
Your agent holds your public key and refuses any release your key didn't sign — before a single line runs.
4 · We can't push code
Even a hacked Infraveil can't produce your signature, so it can't run code on your machine. The switch is yours.
It's optional. The tradeoff is that you sign each release yourself — which is exactly what the most security-sensitive workloads want. If you'd rather not sign by hand, a small approver program — written to your server by the launcher and readable top to bottom — watches for pending releases and signs them on a rule you set (review each one, allow only known builds, or auto-approve). The underlying signer is plain Python you run offline. Still on our side to do: splitting our own release key across multiple parties and adding a public list of revoked keys (see the limits below). But the approval gate above doesn't wait on those — it already shuts us out.
We sign our replies, not just your requests
Many agents prove who they are to the server and stop there. We sign our replies too, and the agent checks that signature before it acts on the replies that change behavior — your encrypted app package and your security rules — using the token it already holds. The check runs in both directions. (This uses a shared secret, so it's verifiable between you and us, not by an outside party.)
Hard limits on what the AI can do
When you turn on automatic fixes, they run inside hard limits enforced in the code, not just asked for in a prompt. Every error is classified, and anything touching login, cryptography, or billing is refused by default — identified first by the code involved, then by the error itself. The AI can't change what those limits forbid.
Details that decide whether a platform holds up in production
None of this shows up in a demo, but all of it is in the running code. This is the work that decides whether a platform holds up in production.
Careful process cleanup
When the agent clears out old processes, it identifies them by markers it set itself — never a blind kill by name. Your other software is never touched.
Traps for scanners
Optional trap routes score a scanner's threat level, record its fingerprint, slow it down, and can serve a decoy response — turning probes into useful data.
Visitor IP can't be spoofed
Forwarded IP and country headers are only trusted from our own verified edge, confirmed with a secret that changes on each restart. A forged X-Forwarded-For gets nowhere.
Built-in proof-of-work
Expensive public actions can require a one-time proof-of-work challenge, tied to your IP and the exact action and run by us — no outside service needed.
Records survive a crash
The main records are written safely to disk as they happen and flushed on shutdown, so a power loss can't lose or corrupt them. We recover the cost elsewhere.
Crash loops can't take over your server
A service stuck restarting is detected, paused with a backoff, and retried automatically — and a leftover supervisor from an old deploy can't bring it back.
Checks health, not just a heartbeat
Services are polled on their health endpoint and restarted when they stop responding — catching the cases where a process is alive but hung.
Logging never slows your traffic
Security and log events go through a queue that drops and counts events under heavy load rather than ever slowing down your live requests.
One-time codes really are one-time
One-time codes are marked used the moment they're used, so a captured code can't authorize a second action — and hardware login can spot a cloned key by its usage count.
Safe local files
Every local file is written to a temporary file, flushed, renamed into place in one step, and locked to the owner only — no half-written files after a power loss, no secrets readable by other users.
Hardened sessions and billing
Login cookies use strict browser protections (__Host- cookies, HSTS, frame-deny, and more). Billing webhooks must carry a valid signature and a recent timestamp, and each event is processed only once — unsigned ones are refused.
The security model is published
The runtime states exactly which algorithms protect requests, replies, and packages, and what each component is allowed to do — so the security model itself can be inspected.
What we can't prove — and won't pretend to
A security page that only lists strengths is just marketing. If you're meant to verify our claims, we have to tell you where the proof stops. So here it is: what you can check yourself, what you can't check yet, and the risks we're still carrying.
What you can verify yourself
- Read the code that runs on your server. The launcher and agent aren't obfuscated. Open them, read every line, and record their outbound traffic with your own tools to see exactly what leaves — this check never runs through us.
- Check our signatures against the public key. Release manifests and sealed exports carry Ed25519 signatures anyone can check against the key we publish — no secret, no trusting us.
- Test the replay protection. Capture a signed request and try to send it twice; the second one is rejected. You can confirm that yourself.
- You own the server. You installed the agent; you can read it, stop it, or remove it at any time. Final control of your machine stays with you.
What you can't verify from us — yet
- A reported hash isn't proof of the live process. A server can report whatever hash it likes. Proving the running process is exactly the published files needs reproducible builds, an outside transparency log, and remote attestation. We don't have those yet.
- A published key can still change. We control the website and the endpoint that serves the key. Making it tamper-proof needs the key pinned through independent channels or recorded in a public log. Not done yet.
- HMAC isn't proof to an outside party. It confirms authenticity only between you and us, the two who hold the secret — it can't prove anything to a third party. Only the Ed25519 signatures above can do that. Where we use HMAC, that's all it gives you.
- Our "second check" is still us. The hash match uses a different endpoint, but it's still our system — so it catches tampering on your machine, not a compromise of our system itself.
- If we were hacked — and how you can now shut us out. Your launcher checks the agent's release signature before running it, and the agent checks the package — so a hacked Infraveil can't quietly swap the agent or your app. Turn on release approval and your agents run only releases you signed offline, with a key we never see and can't forge. The thing you ultimately trust is the launcher you install once — readable source you can check before you run it. Still on our side: splitting our release key across parties, locking runtime dependencies to exact hashes, and a public list of revoked keys.
- We have some power over uptime — and we've reduced it. A billing lock no longer stops your running services: by default they keep serving and only new deploys are paused. Revoked access does shut the agent down — but you own the server and can stop or replace the agent yourself anytime. This still deserves clear contract terms, and a setting that lets you fully control this is on the roadmap.
Your data, stated honestly
On the roadmap, named so you can hold us to it: reproducible builds · runtime dependencies locked to exact, signed hashes · an outside, tamper-evident transparency log with key pinning · remote attestation of the live runtime · release signing split across multiple parties with an offline root key and a revoked-key list · an outside security audit with a published report. Until each one ships, we won't claim what it would prove.
Find a security issue? We'll thank you, not sue you.
A platform that runs inside production needs to hear about problems early. If you find a vulnerability, here's how to report it and what you can expect back.
How to report
- Reach us through the contact page (also listed in our security.txt). Tell us what you found, where, and how to reproduce it.
- In scope: this site, the control-plane API, and the launcher and agent you run on your own machine.
- Out of scope: volumetric denial-of-service, social engineering, physical attacks, automated-scanner noise, and issues in third-party services we don't control.
Safe harbor & what to expect
- Good-faith research is welcome. If you follow this policy — don't access data that isn't yours, don't degrade service, and give us reasonable time to fix before going public — we will not pursue legal action against you.
- We'll respond. We acknowledge reports, work the fix, and credit you if you'd like.
- Honest about the rest: we don't run a paid bounty yet, and a formal third-party audit with a published report is still on our roadmap above — we'd rather say so than imply a program we haven't built.
One path from deploy to day-to-day operations
Log in, connect your server, deploy your app, keep services running, apply security rules, review what's happening, and recover from failures — all through one path. Every deployment follows the same verification and recovery steps.
Why the launcher is separate from your application
The launcher is written in Python. That doesn't limit what you can run.
The launcher handles logging in, syncing with your config, running and restarting the agent, protecting against crash loops, falling back to a cached copy, cleaning up, and coordinating with the host. The agent downloads your encrypted app package, verifies it, starts your services, handles incoming traffic, collects logs, checks health, syncs security rules, and recovers from failures. Your app is described in a config file called infraveil.json, so one setup can run a Node API next to a Python worker, or use Go, Rust, Java, or any other service your server supports.
So you get the same operations across every service, without being tied to one language. Logs, crashes, traffic events, rate limits, scanner traps, and restart behavior all work the same way no matter what your backend is written in.
One Management Path
The launcher manages every service through the same interface, even when your backend uses multiple languages.
Clear Separation
The launcher handles infrastructure. Your application handles business logic. A config file connects the two.
Consistent Security
Traffic rules apply before requests reach your application, so protection stays consistent across Node, Python, Go, Rust, Java, and more.
How the launcher and agent work
The Launcher
What it does: Runs on your server and keeps the host in line with what your config says should be running.
After you copy a one-time install command from the dashboard and run it on your server, the launcher registers the host, signs its traffic to us, downloads the agent, starts it, watches for crashes, and falls back to the last good copy if a fresh download fails.
Security: Install commands are limited and short-lived, launcher requests are signed, and the installed launcher source is readable on your server — so you can inspect it instead of trusting it blindly.
The Agent
What it does: Runs your app and keeps it healthy: downloads the encrypted package, verifies it, starts your services, handles traffic, reports health, and applies your security rules.
The agent runs the services defined in your config and watches them. It unpacks a working folder, runs your install, build, and start commands, polls health URLs, limits how often a service can restart, and keeps the gateway online across every supported language.
Security: The gateway and agent keep infrastructure work separate from your app. Storage paths are spelled out, process output is captured the same way every time, package hashes are checked before anything runs, and restart behavior is consistent across languages.
How they connect
Launcher creates a one-time command -> You log in, the launcher requests a single-use deployment command from Infraveil
Launcher is installed -> You paste the command on your server and the launcher connects the host to the workspace
Infraveil verifies the connection -> The command is confirmed, the host is registered to your account, and agent state becomes available
Agent downloads your application -> The launcher starts the agent, the agent downloads the encrypted package, verifies it, reads the config file, and starts your services
Agent reports health -> Regular check-ins begin, process output, security events, and logs flow to your dashboard
Why a replaceable setup is safer
The security advantage comes from a simple idea: the less that's left lying around, the less there is to attack.
Traditional setups spread code, dependencies, config, logs, and process state across several systems. Infraveil keeps it simple: the config file defines what runs, storage paths are set upfront, and agents are designed to be swapped out cleanly — so when starting fresh is safer than debugging, that's an easy option.
Smaller Attack Surface
Application code is encrypted at rest and runs from a managed workspace rather than scattered across the host. Agents are replaceable, so starting clean is cheap — though the encrypted cache and workspace are persistent files, not nothing (see the limits section).
Built-In Protection
Rate limiting, country blocking, trap routes for scanners, and suspicious pattern detection apply to every deployment without any code changes.
Encrypted Delivery
Application packages are encrypted in transit. Each agent gets its own decryption key, and packages are signed so the agent verifies authenticity before starting.
Why one verified path is faster
Deployments are faster because the whole rollout is one verified path instead of many separate steps.
Traditional setups need separate release scripts, dependency installs, service restarts, and checks. Infraveil bundles it into one signed app package and one path: download, verify, decrypt, set up the working folder, start your services, and report the result to the dashboard.
| Operation | Traditional Deployment | Infraveil |
|---|---|---|
| Code Transfer | Copy files to disk, or download from a repository | Download one encrypted application package over HTTPS |
| Dependencies | Install packages at deploy time (several minutes) | Bundled in the package, installed once at setup only |
| Disk Writes | Multiple writes for code, dependencies, and configuration | Use one managed working folder with set paths and a verified package |
| Service Restart | Restart the service after writing files | Start from a verified package through one managed runtime path |
| Typical Deploy Time | 10-20 minutes | A few minutes |
Why one interface beats stitched-together tools
The real cost of running infrastructure isn't just switching between tools. It's making separate tools that don't talk to each other behave like one system.
A typical backend setup needs a deploy tool, a firewall or security layer, monitoring, logs, traces, alerting, incident handling, a status page, recovery, and someone owning each service. Infraveil doesn't just put those panels side by side. The launcher and agent sit under your services, so deployment state, health, security rules, logs, traces, incidents, status, and recovery all draw from the same data.
Traditional Setup
- Deployment tool (Jenkins, GitHub Actions, CircleCI)
- Security layer (WAF, rate limiting, country blocking)
- Monitoring (Datadog, New Relic, Sentry)
- Log collection (ELK, Splunk, CloudWatch)
- Alerting (PagerDuty, Opsgenie)
Infraveil
- Deploy from the dashboard or API
- Security applied automatically
- Metrics, logs, deployment state, and launcher info in one view
- Security events linked to each deployment
- Automatic fixes for common failures
How security rules are applied
How rules reach your server
You set security rules in Infraveil, and they're delivered through the launcher and agent. Rules and deployments are kept separate, so changing a rule doesn't interfere with a deploy and vice versa.
When you change a rule, agents pick it up within seconds — no redeploy needed. Because the rules are separate from your code, security can change without touching your app.
Protection Layers
- Rate Limiting: Controls how many requests each visitor can make, with adjustable thresholds
- Country Blocking: Allow or block traffic from specific countries based on IP location
- Trap Routes: Fake endpoints that catch automated scanners (e.g., /wp-admin, /phpmyadmin)
- Pattern Detection: Detects SQL injection attempts, path traversal attacks, and suspicious browser signatures
- IP Blocking: Manual blocks and automatic blocks from repeated violations
The ideas Infraveil is built on
Infraveil is built on three ideas: run your backend from one place, treat agents as replaceable, and base every control on the same live data.
Built to Be Replaced
Not "deploy and forget" — deploy and replace. When an agent fails or is compromised, you swap it out instead of debugging it. That's the opposite of the usual patch-in-place approach.
One Source of Truth
Config, security rules, deployment state, live health, and recovery data all live in one place. That's what lets one tool cover so much without stitching together separate products.
Security On by Default
Security, monitoring, status, recovery, and audit records come with every deployment, because they're part of the platform — not extra features you bolt onto your code later.
What this architecture does not claim
Not zero risk: A replaceable setup reduces the attack surface but doesn't remove bugs in your own code. The built-in security catches common attacks, but it's not a substitute for writing secure code.
Not limited to one language: The launcher is written in Python, but your app is config-driven. Go and Node, Python and Rust, Java and anything else — any mix can run through the same dashboard, as long as your server has the right runtimes installed.
Not a replacement for every tool: Infraveil combines deploy, security, monitoring, rollout, rules, keeping services running, and recovery in one place. You may still want specialized tools for compliance reports, deep performance profiling, company-wide identity, or large-scale data warehousing.
Integrations stay at the edges: Slack, Teams, incident.io, GitHub, webhooks, and OpenTelemetry can receive notifications or data, but they don't become the source of truth. Launcher state, agent state, incidents, recovery records, and audit logs stay in Infraveil.
Export is self-serve, not raw database access: You can pull a redacted, signed data and proof export yourself from the dashboard — you don't get direct database access, and larger raw-log archives beyond that may still need a request. We'd rather say that than overstate "you own all your data."