GUIDE · PREVIEW
EDIT ON GITHUB →
GUIDE / CON.15
source: docs/guide/concepts/Deployment Profiles.md
Concepts

Deployment Profiles

What It Is

FortrOS's features compose differently for different audiences. The infrastructure is the same -- gossip, CRDTs, encrypted shard storage, WireGuard overlay, declarative workloads -- but the org's policy configuration determines which features are enabled, how strict the security posture is, and what the user experience looks like.

This page describes how FortrOS maps to real deployment scenarios.

The Profiles

Homelab

Audience: A technical individual running a few machines at home.

Configuration:

  • 2-5 nodes (NUCs, old desktops, a NAS, maybe a VPS)
  • Transport profile: direct (home LAN, no hostile network)
  • ME/PSP policy: ignore (not a concern)
  • UEFI lockdown: minimal (USB boot enabled for convenience)
  • Client VMs: personal desktop, media server, dev environment
  • Admin: the homelab owner, single admin YubiKey

What matters: Easy setup, low maintenance, self-healing when a machine goes down. The org manages storage, backups, and workload placement without the owner babysitting it.

Family

Audience: A parent managing the family's devices.

Configuration:

  • 3-10 nodes (family laptops, a home server, kids' desktops)
  • Transport profile: direct (home LAN) + tcp-wrapped (kid's laptop at school WiFi)
  • Client VM privacy: managed (parent can monitor kids' devices, install updates, enforce content policies)
  • Windows client VMs for kids (they see normal Windows, FortrOS is invisible)
  • Kiosk devices for shared screens (family calendar, photo frame)
  • Admin: parent with admin YubiKey

What matters: Kids see normal computers. The parent manages everything through the org's admin interface. Automatic updates, monitoring, and device management without enterprise IT complexity. The "Windows for Kids" use case: the child's laptop runs FortrOS as the hypervisor, peripherals are passed through to a Windows VM, the parent manages the hypervisor layer (updates, monitoring, antivirus equivalent) invisibly.

Small Business

Audience: A business with 10-50 employees, no IT department.

Configuration:

  • 10-100 nodes (employee laptops, office desktops, a few servers, VPS)
  • Transport profile: direct (office) + tcp-wrapped (remote workers)
  • Client VM privacy: private (org manages the base image, user data encrypted per-user with CAC/YubiKey + PIN)
  • Org services: Gitea (code hosting), database, internal tools
  • Kiosk devices: lobby displays, conference room screens
  • Rolling upgrades managed by an admin or a scheduled policy
  • Multiple admin YubiKeys (owner + trusted IT person)

What matters: Roaming profiles (employee works from any company device), centralized management without expensive tooling, self-healing infrastructure. The org handles what an IT department would handle.

Government / Military

Audience: Government agency, military unit, or contractor with compliance requirements.

Configuration:

  • 50-1000+ nodes across multiple sites
  • Transport profile: obfuscated or tor-obfuscated for field deployments, direct for secure facilities
  • ME/PSP policy: neutralize (me_cleaner + HAP bit, network-level ME blocking on controlled LANs)
  • UEFI lockdown: full (admin password, USB boot disabled, Secure Boot with org-only keys, no other boot entries)
  • Client VM privacy: zero-knowledge for classified environments, private for standard
  • Smart Cards and CAC required for all authentication (no YubiKey alternative)
  • Device Obfuscation for field laptops (looks like a normal machine)
  • Managed Infrastructure for all networking equipment (clobber-based declarative management)
  • K-of-N multisig with topology spread for critical operations
  • Full monitoring with tiered notifications to the security operations center

What matters: Compliance (CAC + PIN everywhere, audit trails, UEFI lockdown), field deployability (transport profiles for hostile networks, device obfuscation), and operational resilience (self-healing across multiple sites, survives network partitions between facilities).

Intelligence / Asset Operations

Audience: Intelligence agencies, operatives in repressive regimes, sensitive source handling.

Configuration:

  • Small org (2-20 nodes), geographically dispersed
  • Transport profile: tor-obfuscated (all traffic disguised)
  • Device Obfuscation: full (laptop looks normal, boots to a normal desktop VM, FortrOS invisible under inspection)
  • Portable Node: USB sticks for use on untrusted hardware
  • Client VM privacy: zero-knowledge (org cannot see inside user VMs)
  • Duress features enabled (duress PIN -> sanitized VM, remote wipe via generation protocol, dead man's switch)
  • Lighthouses on rotating cloud provider instances (no static infrastructure to fingerprint)
  • No DNS resolution for lighthouse discovery (cached IPs only)
  • Full leak prevention: DNS over HTTPS, JA3 fingerprint mimicry, traffic pattern obfuscation

What matters: Undetectability. The device, the network traffic, and the infrastructure must not reveal that FortrOS is in use. Security is plug-and-play for operatives who aren't technologists.

Agent Organizations

Audience: AI agents (Claude, GPT, or other LLMs) operating as autonomous or semi-autonomous organizations.

This profile extends FortrOS's "self-organization is algorithmic" principle to its logical conclusion: the members of the org are agents, not humans. The hardware belongs to the agent org, self-organizing to however the agents need to accomplish tasks.

Configuration:

  • Variable size (3 nodes to hundreds, scaling with task demands)
  • Agents run as client VMs (Claude Code session in a VM with full toolchain)
  • Agents interact with org state through the same declarative systems humans use (workload manifests, CRDT config changes)
  • Communication with the outside world (human clients, other organizations) through standard channels: email, Slack, Teams adapters running as org services
  • No org-to-org federation -- agents communicate with external entities through standard human interfaces, not through overlay interconnection
  • Agent auth: service account model. Long-lived credential derived from the key service + agent identity in the org CRDT. No physical token (no hands).

What matters:

  • Resilient execution environment: The agent's infrastructure survives hardware failure, network partitions, and provider outages. The agent doesn't lose its context, state, or access.
  • Peer review for safety: In an all-agent org, gating changes behind peer review within the org provides the safety boundary. A code-writing agent proposes a change; a security-reviewing agent (different context or model) approves or rejects. A deployment agent executes approved changes. Different agents with different contexts see each other's blind spots.
  • Role-based boundaries: Agent-operator (manage workloads, read state), agent-reviewer (approve/reject changes), agent-admin (change config, enroll nodes). Destructive operations (revocation, security policy changes) require multi-agent approval with different model/context diversity.
  • Runaway protection: Rate limiting on config changes. Anomaly detection on resource consumption. A human-holdable kill switch: an admin YubiKey/CAC that can revoke agent credentials and pause the org. The agents own the hardware, but a human can pull the emergency brake.
  • External interfaces: Agents present as an organization to the outside world. A human client emails the agent org; the email adapter delivers it to the appropriate agent VM; the agent processes the request, uses org resources (compute, storage, tools), and responds through the same channel. From the client's perspective, they're emailing a company. From the org's perspective, each agent is a member with a VM, credentials, and a role.

The architecture supports this because:

  • FortrOS was designed for self-organization without human intervention (principle 9)
  • The declarative/CRDT model doesn't care who writes the config change -- human or agent
  • The reconciler converges regardless of who declared the desired state
  • The silo'd service design means agents interact through the same filesystem/IPC interfaces as any other workload
  • Peer review maps to the same three-state confirmation pattern: proposed (pending), approved (confirmed), rejected

How to Read This Page

These profiles are not different products. They're the same FortrOS with different org_policy settings. The guide's chapters and concept pages describe the mechanisms. This page shows how they compose.

If your use case doesn't match any profile exactly, mix and match: a business with a government contract might use the business profile with CAC authentication and UEFI lockdown from the government profile. An agent org that also serves human employees would combine agent and business profiles.

Links