In private preview
A self-hosted control plane for AI agents that work on infrastructure you own.
It runs the agent loop itself, shows every step, and holds a destructive call for a human before it runs.
- One container, one portPostgres beside it
- Private ranges onlyRFC1918, and consent recorded before the first packet
- Holds destructive calls for a humanwith the plan and its hash
- Any modelAnthropic, OpenAI, Google, or any OpenAI-compatible endpoint
- Apache-2.0 licensedin private preview
The problem
Four questions before an agent touches anything
An agent on infrastructure it did not build needs four answers. They are separate problems, and treating them as one is why this is usually harder than it should be.
What is out there?
A mixed, self-hosted estate rarely has an inventory anyone trusts. Before anything else, something has to look.
May I touch it, and how do I get permission?
One real network turned up twenty-six services in under a minute: twenty-six admin interfaces, each minting a differently named credential in a different place. An MCP server assumes you already hold that credential.
How do I call it, safely and cheaply?
A tool that can restart a service can also delete one. The difference has to be known before the call, not guessed from its name afterwards.
What does the model need to know?
How that system is read without changing it, which of its operations destroy something, and where it keeps its own schema.
Where Glion stands
Several projects do one of these jobs well, and nothing we found does all four for a mixed, self-hosted estate. That is the reason Glion exists; it is not a claim that the gap is large. Glion is not better than HolmesGPT at Kubernetes, n8n at SaaS workflows, or Nango at OAuth. It joins four jobs that are usually four tools, for an estate none of them is aimed at: one where you do not yet have a list of what you own.
How it works
Four steps, in the order they depend on each other
Step 1
Scan your network
Name a private range and Glion sweeps it with plain TCP connections: no logins and no credentials, and nothing beyond what a service offers to identify itself. It never connects to a print server or an industrial-control port, asks for no API key, and names what it finds with the bytes that named it.
Step 2
Connect with the least privilege
For each find, Glion links to the page in your own instance that mints its token and says the least privilege that will work, such as PVEAuditor on Proxmox: read everything, change nothing. It never asks for a login password, and a credential counts only once a call to the service has worked.
Step 3
Build an agent with grants and a budget
Pick any model, grant tools one at a time, and set a budget. A subagent cannot spend more than its parent has left. An agent can decide its next step by asking the model, or run a fixed plan and ask nothing.
Step 4
Answer the calls it holds
Reads run. Writes wait. A destructive call stops with its arguments, what it acts on now and the hash of the plan, until someone approves or denies it, and it is denied if nobody answers in time. At commit the target is read again; a plan that changed is asked about again, never retried.
The film
Glion in 90 seconds
The console as it runs: a scan, a credential, an agent with a budget, and a destructive call held until someone approves it. It has narration and captions. Captions are part of the picture; the caption track is for screen readers and custom caption styles.
Read the transcript, with what is on screen
Glion is a control plane for agents that do real work on machines you own.
On screen: The Glion mark draws itself on a paper-coloured ground: a rounded square, a line, and a lime dot. The name Glion appears beside it, and the same sentence underneath.
Before an agent touches infrastructure it did not build, four questions need answers. What is out there. May I touch it. How do I call it safely. What does the model need to know. Nothing we found answers all four for a self-hosted estate. That is why Glion exists.
On screen: Under the heading "Four questions, before an agent touches anything", the questions arrive one at a time, numbered 01 to 04, each underlined. A faint column of service names runs down the right: proxmox-ve, portainer, opnsense, postgresql, grafana, home-assistant, coolify and others. The last two sentences appear in turn below the questions.
It starts with your own network — private ranges only, no key required — and names what is there.
On screen: The Glion console, on Inventory, "Scan a network": "Your own network, private ranges only, audited before the first packet." A private /24 range is typed and Scan is pressed. Six services appear one by one, each tagged identified, with the credential it needs: Proxmox VE (API token, PVEAuditor), Portainer (access token, read-only), OPNsense (API key, read-only), PostgreSQL (a role with SELECT only), Grafana (a service account, Viewer) and Home Assistant (a long-lived token, read-only).
For each find, it knows which page mints the token, and the least privilege that will work. Every credential is verified before it counts.
On screen: Credentials, Proxmox VE, native driver, recommended. Why this method: Glion speaks it directly, read-only unless you grant more. Where to mint it: Datacenter, Permissions, API Tokens, Add, with a button, "Open in your Proxmox". Least privilege that will work: PVEAuditor. A token is pasted into the field and Verify is pressed; a tag reads "verified, 3 nodes, 14 guests". Below, under "Also connected", Portainer, OPNsense, PostgreSQL, Grafana and Home Assistant turn to verified one after another.
Then an agent: any model, tools granted one at a time, and a budget. A provider is a row in a table, not a deploy.
On screen: Agents, Ops, a draft. Model: a table of providers with context size and price per million tokens: Anthropic claude-sonnet-5, OpenAI gpt-5, Google gemini-2.5-pro, and qwen3 on an Ollama machine on the LAN, unpriced. The pointer picks the Anthropic row. Connectors: "Registering a server grants nothing until a tool is checked." Four tools are ticked in turn: proxmox.vm.list, proxmox.vm.status and portainer.containers.list, each read, "runs without asking"; and proxmox.vm.delete, destructive, "held for approval". Limits: max cost $2.00, max turns 40, max tool calls 120, max tokens 400k. Publish is pressed.
It runs the loop itself and shows every step. Reads run, writes wait, and a destructive call holds until a human answers.
On screen: Fleet, Ops. The task: free disk on the Proxmox host by removing runners stopped for more than 90 days. Three read calls have run, in 0.3, 0.2 and 0.4 seconds. The model says runner pve-old-runner (104) has been stopped for 118 days and is the only candidate. Then proxmox.vm.delete on vmid 104, destructive, needs approval. A card opens: the arguments in full (vmid 104, purge true, node pve); what it acts on now (runner pve-old-runner and its 38 GB disk on node pve); the plan hash, sha256 3f9c…b21e; expires in 4:58; and Approve and Deny buttons. Approve is pressed. The call reads "approved by you, ran, 1.2 s", the session is done, and the outcome reads "Removed runner 104 and its disk; 38 GB freed."
Every session and its subagents, as one live tree.
On screen: Fleet: 3 active, 0 awaiting approval, $0.42 spent, 0 failed. Ops, on Anthropic claude-sonnet-5, is coordinating three subagents and has spent $0.42 of $2.00. Beneath it, joined by lines: inventory on OpenAI gpt-5, reading portainer.containers.list, $0.08 of $0.50; verify on Ollama qwen3, checking backups of VM 104, $0.00 of $0.25; and report on Anthropic claude-haiku-4-5, queued and waiting for verify, $0.00 of $0.25.
Self-hosted: on your LAN, behind your egress rules, on hardware you own. One container, one port.
On screen: Paper again, with the mark in outline on the right. Three lines, each underlined: "On your LAN." "Behind your egress rules." "On hardware you own." Then a command, docker compose up, and beneath it "one container · one port · Apache-2.0".
Glion.
On screen: The solid mark and the name Glion, with the line "A control plane for building and operating AI agents."
Self-hosted
On your network, with a person on the risky calls
Where it runs
- On hardware you own, behind your egress rules. One container and one port, with Postgres beside it.
- The console is published on loopback until you open it. Put TLS in front before you do, and reach it over a VPN or an overlay network rather than the open internet.
- Provider keys and connector credentials are encrypted at rest with AES-256-GCM, decrypted only for the call, and never logged, returned to the browser or written to the audit log.
- A native driver passes a service's responses through an allowlist of fields, so a password a service returns does not reach the model.
- A scan covers private ranges only, a /22 at most, and is an operator's action: an agent cannot start one.
What waits for a person
- Policies attach to classes of action, not to agents, so a new agent inherits them. Every policy says how long a held call may wait before it is denied; waiting forever is a box someone has to tick.
- An approval is of the plan's hash. If the target has changed by the time the call commits, the call is asked about again.
- A policy can ask for two approvers and refuse self-approval, and every decision is made by a named account.
- Some calls are refused outright, and no approval overrides them.
- Every session, and every subagent under it, is one live tree showing what each is doing and how much budget it has left.
What this does not fix
Whatever the host Glion runs on can reach, an agent can reach. That is what makes it useful, and it is the whole risk. Text an agent reads, such as a container log or an issue, can carry instructions. No network control stops that; holding the destructive calls for a person is the layer that does, which is why Glion has one.
Glion's threat model and controls were checked in an internal security review in September 2026.
Integrations and models
What it connects to
Native drivers
Proxmox VE · OPNsense · Portainer · Coolify
Nothing to install. Whether a call reads, writes or destroys is written in the driver, not guessed from a tool's name.
Any MCP server
HTTP · SSE · stdio
No vendor allowlist and no cap on connectors. Tools are discovered from the server and granted one at a time. SSH is there too, as the last resort, and never recommended.
Any model
Anthropic · OpenAI · Google
And any OpenAI-compatible endpoint: OpenRouter, Groq, Together, DeepSeek, Mistral, vLLM, LM Studio, Ollama. A provider is a row in a table, not a deploy, and a subagent can run on a different vendor from its parent.
Pricing
Free to run yourself
Community
Free
Forever, self-hosted
Free forever, self-hosted, and everything Glion does today.
- Everything Glion does today
- Self-hosted, on infrastructure you own
- No caps on connectors, accounts or deployments
Pro
US$99 a month
or US$990 a year, per deployment
One licence is one deployment. Checkout through Paddle, the merchant of record, which handles tax and invoices.
- Email support
- A year of updates
- Business features for identity and auditto be announced
Ultra
Contact sales
No list price
For MSPs and teams that run many deployments.
- Many deployments under one agreementplanned
- Clusteringplanned
- 24×7 supportplanned
Questions
Before you ask
What is Glion not?
Not a hosted service. There is no Glion cloud. You run it, on a machine you own, and it reaches what that machine can reach.
Not Kubernetes-only. It is aimed at a mixed estate: hypervisors, firewalls, container hosts and whatever a scan turns up. If Kubernetes and observability are all you run, HolmesGPT is the mature answer.
Not a chatbot. There is no chat. You give an agent a task, a schedule or a plan, and the console shows what it does.
What data leaves my network?
Calls to the model provider you choose, and nothing else that Glion sends on its own account. Connectors you add reach what they are pointed at, and an MCP server started with npx or uvx is downloaded from its registry. Those calls carry the task and what the agent's tools have read, so choose the provider with that in mind; with a local model, such as Ollama, vLLM or LM Studio, they need not leave the LAN at all.
An agent reaches only the tools you grant it, and its web fetches are checked against the environment's egress allowlist.
What does it need to run?
Docker and Postgres. docker compose up starts Glion with a pinned Postgres beside it, generates the database password and encryption key, and prints a console password once unless you set your own. Then give one model provider a key.
Can I put it on the internet?
It will work, and we would not. Reach it over a VPN or an overlay network, and put TLS in front of it first. If it must be public, put an identity-aware proxy in front of the TLS.
How do I get it?
Glion is in private preview. Write to [email protected] and say a little about what you would run it on.
Put an agent on your own infrastructure, with a person on the risky calls.
Glion is in private preview. Tell us what you run, and we will be in touch.