Ironveil Systems is an Arizona LLC doing architecture, security, monitoring, migrations, and managed hosting — as your ongoing provider or as the team that sets it up and teaches you to run it yourself. Either way you get the configuration, the documentation, and a written account of what each control stops.
01 / WHAT WE DO
We work as an MSP directly, and we take escalations from other MSPs — the infrastructure problem that has outlasted two vendors, the migration nobody wants to own, the outage whose cause is still unexplained. Subcontract or white-label, your client relationship stays yours.
Network segmentation, hypervisor layout, storage and backup design for Proxmox, bare metal, and mixed environments. We write the topology down, including the parts that are compromises, and hand over the diagrams and the runbooks.
Firewall policy, host hardening, patch and release process, key handling, log collection that someone actually reads. Work starts with a written threat model so it is clear which attacks the result addresses and which it does not.
Standing up mail, identity, version control, monitoring, and web hosting on infrastructure you own. Includes the unglamorous half: restore testing, upgrade paths, and an honest estimate of the operating hours it will cost you.
Managed web hosting on our stack or yours, and moves between them: server to server, on-premises to cloud, cloud back to hardware you own. Migrations run with a rehearsed cutover, a rollback plan, and a maintenance window we commit to in writing.
Day-to-day administration and architecture across Azure, other clouds, Linux and Windows fleets: identity, networking, backup, patching, and cost. We have designed multi-tenant Entra ID estates with delegated business-unit administration — management groups, RBAC, Privileged Identity Management — and documented them so someone else can run them.
We can place dedicated NVIDIA H200 capacity and isolated AI environments in a SOC 2 Type II and ISO 27001 audited Midwest data center. We architect the environment, set the access and network boundaries, and operate it — your data and models stay inside it.
Policy, control mapping, audit preparation, and risk assessment, handled by credentialed GRC practitioners on our team. If compliance work is what you need, say so when you write and we will put you in front of the right person rather than improvising it.
For individuals with real exposure: reducing the personal data already public, separating identity from address and phone, hardening devices and accounts, and building habits that hold. Starts with a written threat model, because privacy work costs convenience and you should know what you are buying.
Applied work on privacy properties of communication systems, plus the tooling that comes out of client engagements. Results are published when they hold up, and withdrawn when they do not.
Software companies and operators we have done infrastructure, security, or platform work for.
02 / OPEN SOURCE
A provisioning system that builds hardened WordPress hosts on Proxmox VE. You give it a host and a site list; it produces segmented VMs or containers, a default-deny firewall policy, signed releases, and backups it verifies by restoring them.
Written for MSPs and small teams who run client sites and would rather not rebuild the same stack by hand every time. It is opinionated about layout and process, which is the point: the same shape every time is what makes an incident tractable at 2am.
MIT licensed. No hosted control plane, no telemetry, no account. Read the code before you run it.
You can also have us run it. Our managed hosting is WASP on our hardware: we handle provisioning, patching, signing keys, and the restore tests, and you get the same segmentation and firewall policy as a self-hosted install. Because the stack is the open one, leaving means taking the configuration with you rather than starting over.
WHAT IT GUARANTEES
WHERE IT STOPS
ARCHITECTURE, ANIMATED
Five diagrams of how a WASP host is laid out and how traffic, releases and imported sites move through it.
03 / RESEARCH & DEVELOPMENT
We keep a research line running alongside client work. Both programs below are under investigation rather than for sale, and both are described here at the stage they are actually at.
Neither has been through third-party review. Where we have measurements, they come from our own lab under conditions we chose, which is a weaker claim than it sounds and we would rather say so than imply otherwise.
PROGRAM 01
Security operations tooling that rebuilds its own compromised hosts. Working lab build.
PROGRAM 02
Privacy-preserving communications
How much metadata leakage a usable messaging system can shed. Simulation only.
PROGRAM 01 · HOLLOW — ACTIVE RESEARCH
HOLLOW is an assembly of open-source security tools — detection, threat intelligence, firewalling, and workflow automation — provisioned as code onto a virtualization host and wired so that detection, enrichment, and response happen without someone reading a dashboard first. We name specific components in the design document rather than here, because we replace them as better ones appear.
The name is the design decision: hosts are treated as disposable. A host that trips two independent high-confidence signals is snapshotted for forensics, destroyed, and rebuilt from the same definitions that created it. Nothing gets patched in place and trusted afterward.
It runs as a set of VMs on the same stack as WASP, or on a standalone node if you would rather keep security tooling off the hosts it watches. We recommend the second.
STATUS — READ THIS FIRST
ARCHITECTURE
Nine layers. Each row lists what runs there and what it is responsible for; the stage number marks where it sits in the path from signal to response.
01
infrastructure-as-code · virtualization · configuration management
Every VM and network is defined in version control. Rebuilding a host is running the same definition again, which is what makes destroy-and-replace a viable response instead of a last resort.
02
host agents · network inspection · firewall policy
Host agents for file integrity and log collection, network inspection at the segment boundary, firewall policy as the enforcement point. Two independent signals per event, so a single noisy rule cannot drive a rebuild on its own.
03
honeypot services · session logging
Services that exist only to be touched. Nothing legitimate connects to them, so a connection is a high-confidence signal rather than something to correlate. This is the cheapest true positive in the stack.
04
indicator store · public threat feeds
Indicators from public feeds and from your own incidents, used to add context to an alert. Enrichment tells you whether an address is already known. It does not tell you whether the alert was real.
05
automation tooling · local language model
Workflows are explicit and readable: this alert, these conditions, that action. A locally hosted model reads the logs and scan findings behind an alert, names the flaw it thinks caused it, and either presents the remediation for approval or applies it directly when that class of fix is on an approved list. Anything outside the list is proposed, not performed.
06
containers · OSINT collection · memory and disk forensics
Analysis tools run in containers created for one job and destroyed after. Malware analysis and OSINT collection are the tasks most likely to end badly, so they get the shortest lifetime and the least network access.
07
firewall rules · chat and email notification
Automatic actions are limited to ones that are cheap to undo: block an address, isolate a segment, page a human. Anything destructive waits for a person. Every action is logged with the alert that caused it.
08
Snapshots · offsite replication · restore tests
Snapshot first for evidence, then rebuild from source. Backups replicate offsite and are restored on a schedule into a scratch VM, because an untested backup is a guess. Rebuilding alone would restore the host and leave the flaw, which is why the orchestration layer has to identify and close the cause.
09
attack tooling · scripted playbooks
Scripted attacks run against the stack on a schedule to check that detections still fire and workflows still complete after changes. A detection nobody exercises is a detection you do not have.
SIZING
Driven by log volume rather than license tiers. Three configurations we design against; our lab node sits at the bottom of the middle one.
SMALL · UNDER 50 ENDPOINTS
MID · 50–500 ENDPOINTS
LARGE · 500+ ENDPOINTS
DISCONNECTED ENVIRONMENTS
Air-gapped controls, OT segments, and legacy equipment are where most monitoring stops, because most collectors assume the device can reach them.
We support five routes for getting logs out of a machine that cannot reach the network: a one-way hardware diode, a buffered collector transferred in batches, an isolated bastion host, scanned removable media, and serial console capture. Only the diode is real-time without creating a return path. The rest trade latency or labor for the air gap, and we will tell you which one your environment actually needs rather than selling you the expensive one by default.
THE HONEST VERSION
Known gaps: no multi-node testing, no third-party review, and automated rebuild is currently limited to hosts with no local state. Model-driven root-cause remediation is the newest part of the design and the least proven; treat the approved-fix list as short until we can show otherwise.
PROGRAM 02 · PRIVACY-PRESERVING COMMUNICATIONS — ACTIVE RESEARCH
Content encryption is settled. Metadata is not. Who talked to whom, when, how often, and from where survives most deployed systems, and it is frequently the more revealing half.
Our program measures how far that leakage can be reduced against stated adversaries — a passive network observer, a hostile server operator, a partial global observer — while the system stays fast enough that people keep using it. Padding, batching, cover traffic, and delay all buy privacy with latency or bandwidth. We are trying to quantify the exchange rate rather than assert one.
This is research. There is no product, no beta, and no date. What exists today is a threat model, a simulation harness, and results we do not yet trust enough to publish.
If your work depends on metadata resistance, we would rather talk about your constraints than sell you something that is not finished.
Status: active investigation. Findings published when they survive review.
04 / HOW WE WORK
01
Hosted services are a fine choice when you make it deliberately. We start from infrastructure you own, then add outside dependencies one at a time, each with a reason and an exit.
02
Every control we ship comes with the attack it stops and the attack it does not. A control whose boundary nobody wrote down gets trusted past its design, which is how people get surprised.
03
Configuration lives in files you can read and diff. No black-box agents, no vendor console holding the only copy of the truth. If we leave, everything needed to keep running stays with you.
Larger engagements run in phases — envisioning, planning, developing, deploying and stabilizing — adapted from the Microsoft Solutions Framework. Each phase ends with a written artifact: a scope, a design document, a risk assessment, a pilot and acceptance plan, and a handover to whoever operates the system next.
05 / CONTACT
Describe the environment and the problem. We will reply with what we would look at first and whether we are the right people for it.
Ironveil Systems LLC · Arizona, United States
SIMPLEX
End-to-end encrypted chat with no phone number, account, or user ID. Use this if you would rather not put the details in email.
WHAT TO INCLUDE