Documentation

Deployment Guide

Deploy Infraveil on your own server. The launcher installs on your host, your application loads from a config file, and everything around it -- proxy, TLS, networking, and data -- stays under your control.

How It Works

Log in to the dashboard, install the launcher on your server, register it, verify the application package, and publish it behind the gateway.

Overview

The installer package is not your application itself. It sets up an authenticated connection to Infraveil, downloads your approved application files, verifies they have not been tampered with, and starts the services defined in your config file on your own server.

Your infrastructure stays conventional: your own server, system service registration, reverse proxy, TLS, and local logging. The installer sets up the launcher, while your application is config-driven and can run Node, Python, Go, Rust, Java, or any other service your host supports.

Application scope
Config-driven services
Data location
Your own server
Recovery
Replace, restart, or redeploy

Requirements

Linux or Windows host

A server that can run the launcher and whatever runtimes your application needs: Node, Python, Go, Rust, or Java.

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.

Deployment

Run the first install on a private server. Test everything locally before making your service public.

1. Create the service user and application directory

sudo adduser infraveil-agent
sudo mkdir -p /home/infraveil-agent/app
sudo chown -R infraveil-agent:infraveil-agent /home/infraveil-agent/app

2. Copy the installer to your server and run it

scp /path/to/launcher.py infraveil-agent@your_server_ip:/home/infraveil-agent/app/
sudo su - infraveil-agent
cd app
chmod +x launcher.py
python3 launcher.py

3. Review the configuration file

nano Customization/config.json

{
  "port": 5050,
  "endpoint": "/",
  "message": "Service ready",
  "rate_limit": "5 per minute"
}

Proxy and TLS

Register the service, put NGINX in front of it as a reverse proxy, and add TLS before making it public.

sudo nano /etc/systemd/system/infraveil.service

[Unit]
Description=Infraveil Agent Service
After=network.target

[Service]
Type=simple
User=infraveil-agent
Group=infraveil-agent
WorkingDirectory=/home/infraveil-agent/app
ExecStart=/usr/bin/python3 /home/infraveil-agent/app/launcher.py
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl enable infraveil.service
sudo systemctl start infraveil.service
sudo apt update
sudo apt install certbot python3-certbot-nginx -y
server {
    server_name api.yourdomain.com;

    location / {
        proxy_pass http://127.0.0.1:5050;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Operations

Test locally before going live. The dashboard operations layer is backed by real machine signals: launcher sync reports host health, running agents, cached agents, crash-loop suspension, fetch failures, process state, and resource pressure; agent heartbeat reports payload hash, supervised service state, restart pressure, queue pressure, dropped events, fallback state, and runtime metrics. Infraveil uses that evidence to build incidents, public status, and the service catalog.

curl http://127.0.0.1:5050/
sudo systemctl status infraveil.service
sudo nginx -t

Recovery and redeployment

If your server is compromised, the service becomes unhealthy, or the install command is revoked, redeploy from a fresh package. Old sessions are designed to be replaced, not repaired.

The clean recovery path: restore a trusted server state, deploy a fresh package, test locally, then open it to traffic again.

Documentation Position

Documentation is part of the trust model.

The documentation page is not only setup instructions. It is a strategic surface because it answers the question every serious customer eventually asks: what is actually happening on my machine? Infraveil should make that answer visible, boring, and precise. The launcher installs locally. The service runs on customer infrastructure. The application remains config-driven. The gateway, proxy, TLS, service user, and recovery path stay understandable instead of disappearing behind a vague cloud promise.

This matters because incumbents can question trust by implying that centralization means opacity. The documentation has to answer the opposite: centralization can make the system easier to inspect when the runtime path is documented clearly. The stronger the setup and recovery model is explained, the harder it is to claim that Infraveil is asking for blind dependence.

The correct standard is that a technical operator should be able to read the docs and understand the shape of control: what runs locally, what connects outward, what is verified, what can be restarted, what can be replaced, and how recovery should happen. That turns documentation into technical clarity.

Documentation Standard

The install path should be explainable end to end.

Docs for a platform like this cannot be shallow setup notes. They have to explain the operating contract. What is installed? What runs locally? What connects outward? What does the launcher control? What does the agent supervise? What data is sent? What can be restarted? What can fail safely? What does the customer remove if they leave?

The documentation should reduce mystery. It should make the platform easier to challenge, not harder. A customer should be able to read it and understand the deployment path, runtime model, recovery behavior, permissions, and support expectations before they commit critical workloads. That is not a nice-to-have. It is how a centralized platform earns trust.

Good documentation also protects the category. If the docs clearly show launcher authority, agent verification, gateway behavior, manifest-driven services, policy decisions, and recovery flow, then the product is harder to mislabel as a dashboard or wrapper. The docs become the map between the marketing claim and the actual machine.