Five current steps: authorize in Trust Console, browser-verify the customized infraveil.py, consume the five-minute one-use bootstrap capability, verify the host-bound launcher installation and Trust & Receipts state, then validate infraveil.json before managing services.
Overview
The installer is not your application. It opens an authenticated connection to Infraveil, downloads your approved app files, verifies their integrity, and starts the services your config file defines — all on your own server.
The setup uses standard components: your own server, a system service, a reverse proxy, TLS, and local logs. The installer sets up the launcher. Your app is driven by config and can run Node, Python, Go, Rust, Java, or anything else your host supports.
Requirements
Supported Linux host
A Linux server that supports systemd and the runtimes your application needs: Node, Python, Go, Rust, Java, or another compatible runtime. The commands below are Linux-specific.
Administrative access
Admin access to create users, register the service, and set up the reverse proxy.
DNS and network
A domain name, inbound HTTPS access, and outbound HTTPS to Infraveil.
Launcher install command
A one-time install command from the dashboard after logging in and selecting your workspace.
Authenticated enrollment and deployment
Use the authenticated Trust & Receipts / Trust Console flow for the current hosted product. Older standalone instructions that create an infraveil-agent user, copy launcher.py, or edit Customization/config.json are legacy examples, not the current installation procedure.
1. Authorize in Trust Console
Keep the customer Ed25519 release-signing private key under customer control. Trust Console issues a scoped bootstrap capability that expires after five minutes and is usable once.
2. Verify the customized installer in the browser
Download the customized infraveil.py presented by Trust Console only after the browser verifies its published hash. Do not substitute an old standalone launcher script or an installer from another workspace.
3. Enroll the supported Linux host
Run the verified customized installer with the five-minute one-use bootstrap capability. The enrollment exchanges it for a host-bound, one-use launcher ticket; neither capability is a reusable bearer credential.
4. Verify installation and trust state
Confirm the installed launcher identity, host binding, customer release key, and reported Trust & Receipts state before assigning managed services. The current elevated Linux/systemd install defaults the launcher service to root; it is not a rootless or no-system-change installation.
5. Define the runtime contract
Review and validate infraveil.json for the installed release. It defines the managed services, commands, ports, health checks, routes, and relevant policy inputs. Release approval is separate from host enrollment: manual, exact-hash allowlist, and automatic modes have different human-veto behavior.
Managed routes, proxy, and TLS
The authenticated installer manages the current launcher registration. The elevated Linux/systemd path currently defaults that launcher service to root. Do not recreate the legacy infraveil-agent/launcher.py unit shown in older standalone documentation.
Review the runtime contract
Use the validated infraveil.json to identify service ports and configured managed routes. Confirm launcher reporting and the configured local health probe before exposing traffic.
Keep the network boundary explicit
Configure DNS, TLS, and any upstream edge protection appropriate for the environment. Infraveil origin-side gateway policy applies only to configured traffic that reaches the managed gateway; it does not protect saturated links, upstream volumetric attacks, or bypass listeners.
Operations
Check the service locally before you go live. Use the commands below to confirm the app responds, the system service is running, and your NGINX config is valid.
Once it's live, the dashboard shows what each server is doing, so you don't have to SSH in to find out. The launcher reports host health, which agents are running, crashes, restart loops, and resource pressure. Each agent reports its app version, service state, dropped events, and runtime metrics. Infraveil turns that record into incidents, a public status page, and your service catalog.
curl http://127.0.0.1:5050/
sudo systemctl status infraveil.service
sudo nginx -tRecovery and redeployment
If your server is compromised, the service goes unhealthy, or the install command is revoked, redeploy from a fresh package rather than patching what's there. Old sessions are meant to be replaced, not repaired.
The recovery path is the same every time: restore the server to a trusted state, deploy a fresh package, test it locally, then open it to traffic again.