What Glion can and cannot do

Written for someone opening it for the first time. Verified against the running instance on 2026-09-07, not against the roadmap.

---

The one-sentence version

Glion runs AI agents on your own server, gives them tools through MCP, and holds the dangerous calls until you say yes. It is a control plane for unattended work, not a chat app.

---

Can it control my home lab?

Yes, and it is the thing it is best at. Verified end to end on the deployed instance: all three MCP transports discover tools, npx and uvx both fetch and run published servers, and the container reaches both the LAN and the internet.

The shortest path for the most common targets:

Then grant the agent the individual tools, and write an approval policy for the destructive ones. Registering a connector grants nothing on its own.

The honest caveat. The agent runs inside the Glion container, on the host Glion is deployed to. Whatever that host can reach on your network, the agent can reach. That is what makes it useful and it is the entire risk.

---

If I put this on the internet, will it still work?

It will work. Whether you should is a different question, and the answer today is no.

Right now the console is reachable only on your LAN, over plain HTTP, behind one password. The setup panel reads your actual request and says which of those apply. If you expose it as-is:

• One shared password means no identity, no MFA, no revocation, and no way to answer “who ran that”. It is also directly brute-forceable.
• Plain HTTP hands the password to anything on the path.
• A console that can run shell commands on a LAN host is a well-known target. Exposed Docker APIs have been harvested by Shodan-driven worms for years, and this is strictly worse: it skips the container step.
• Prompt injection turns your own agent into the attacker. If it reads a container log, a Grafana annotation or a GitHub issue, that text can carry instructions, and the agent executes them from inside your network with your credentials. No network control stops this. Per-action approval on the destructive tools is the only layer that does, which is why Glion has one.

If it must be reachable: a VPN or an overlay network is the answer, and an identity-aware proxy in front of TLS is the answer if it cannot be. Both Home Assistant and Portainer tell you the same thing in their own docs.

---

What you can do today

Run agents on any model. Ten providers are pre-listed — Anthropic, OpenAI, Gemini, OpenRouter, Groq, Together, DeepSeek, Mistral, a local Ollama, and a generic OpenAI-compatible entry. Add a key and pick a model. A subagent can run a different vendor from its parent.

Two ways to orchestrate. An LLM agent decides what to do next by asking a model, and can delegate to subagents. A workflow agent runs a plan you write — steps in order, branches in parallel, loops with a ceiling — and asks nothing. Steps hand results to each other through session state.

Watch it happen. The Fleet shows every running session and subagent as one live tree with what each is doing right now. The session inspector nests a subagent’s trace at the point of the handoff.

Connect anything. MCP over HTTP, SSE or stdio, no cap. Grants are per tool per agent, re-checked on every call. A tool can be blocked org-wide.

Hold the dangerous calls. Policies attach to classes of action, not to agents, so a new agent inherits the guardrails. Every policy declares an auto-deny timeout.

Run unattended. Five-field cron schedules, with a preview of the next five runs.

Keep the output. Agents save versioned files you can preview and download.

Operate it. Spend cap, concurrency, a shell master switch, retention with a sweep that tells you what it would delete, an audit log, and a full trace of every session.

---

What you cannot do

Talk to a running agent. You can steer it — push text into a queue it reads on its next turn — but there is no reply channel. This is the biggest gap against every competitor, whose primary interface is a conversation.

Trigger it from anything but a person or a clock. No webhooks. The API is cookie-authenticated, so nothing external can start a session.

Give it a knowledge base. No document indexing, no retrieval. Skills are instructions, not documents.

Let it remember. An agent starts every session knowing nothing about the last one. Session state lasts for one run.

See every run of one agent. History is per session. There is no “which step of this agent usually fails” view, though the data is there.

Edit a command before approving it. You can allow or deny. The backend supports an edited input; no screen offers it.

Evaluate it. No eval suite. The screen says so and shows the regression signal from real runs instead.

Have more than one user. No accounts, no roles. The approvers field on a policy is advisory.

Survive a rate limit or a crash mid-run. A 429 that outlasts two retries fails the whole session. A restart closes running sessions with an explicit trace event rather than resuming them.

---

How it compares

Where Glion is genuinely ahead: authority. Nothing else in this table grants tools individually per agent, classifies each one read/write/destructive from the server’s own declared hints, blocks a tool org-wide, and gates action classes behind a human with a mandatory auto-deny timer. If what you care about is an agent that can touch real infrastructure without being able to surprise you, that is the difference.

Where it is behind: conversation, triggers, retrieval, and durability. If you mostly want to chat with an agent about your documents, use Dify. If you want the shortest path to “agent does a thing on a timer with a hundred integrations”, use n8n.

---

Use cases, concretely

Five jobs Glion is actually shaped for. The first is the one to start with, because everything it needs is already reachable from the container.

1. Night shift on your own stack

Verified reachable from inside the Glion container today: northwind-api:4000 by its Coolify network alias, the Postgres on the LAN, and the internet.

At 02:00, query northwind.events for rows where processed_at is null and older than an hour. Check the API answers. Report what you find. If anything needs restarting, ask me first.

A Postgres MCP server gives it one query tool, classified read-only. A policy on destructive holds anything that writes. You wake up to a report, or to an approval waiting.

2. Gated hands-on-production

The case the approval gate exists for. An agent that can restart a service, roll a deployment or issue a refund — and cannot do any of it until someone taps Allow, with a timer that denies by default if nobody does. Every attempt, allowed or not, is in the audit log under the agent’s own identity.

3. Home lab caretaker

Home Assistant over its own MCP endpoint, Docker and Grafana over uvx, Kubernetes over npx. Read-only tools granted freely; the destructive ones behind a policy. On a schedule, unattended.

4. Fan-out research with a cost floor

A workflow agent runs three lookups in parallel on a cheap model, writes each answer to a state key, then one expensive model writes the summary. The delegation map shows the carve-out; the cost meter shows what it actually cost.

5. A recurring report nobody wants to write

Weekly digest, changelog from merged PRs, a compliance sweep. Honest note: n8n and Dify do this better, because they have a hundred integrations and you have MCP servers. Use Glion for it only if it already lives here.

---

How this differs from a personal assistant

People compare Glion to OpenClaw and Hermes Agent. They are the same category as each other and a different category from this.

If you want an assistant you text, use one of those. They are years ahead, MIT, self-hostable, and enormously better at it. Glion has no chat at all.

What they say about themselves is the reason Glion exists. Hermes’ docs: the tool denylist “does not sandbox a hostile or compromised agent”, and every authorized chat user “shares the owner’s OS identity”. OpenClaw’s: adversarial or mutually untrusted users on one gateway is “not supported”, and “everyone who can message a tool-enabled agent shares that agent’s delegated tool authority”.

That gap has been expensive. OpenClaw had a one-click RCE that worked against instances bound to localhost (CVE-2026-25253), tens of thousands of publicly exposed gateways in the weeks after launch, and hundreds of malicious skills in its registry. Cisco shipped DefenseClaw, a third-party governance layer, to sell into that gap. Glion is that layer, built in rather than bolted on — which is worth exactly as much as governance is worth to you, and no more.

---

Letting other people use it

There are no users today. The identity is the literal string operator, there is not one tenant column in the schema, and every human action in the audit log is attributed identically. Agent actions are attributed properly (slug/session); human ones are not.

Glion is also always the MCP client — it dials out and never listens. So for it to touch someone’s systems, those systems must be reachable from Glion’s host. On your LAN that is free. Across the internet it is the whole problem.

Reaching a stranger’s home lab is a supported flow, and NAT is still the wall

Two separate problems, routinely conflated.

Authorization is solved and standardised. MCP’s spec covers exactly this: the client gets a 401 carrying WWW-Authenticate, reads /.well-known/oauth-protected-resource, discovers the authorization server, and runs PKCE with a resource parameter. Home Assistant already implements it — IndieAuth, where the client id is just your app’s base URL. So “a user connects their Home Assistant to my hosted Glion” is a flow to implement, not one to invent. Note two recent changes: Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents, and passing a user’s token through to a third-party API is forbidden outright — the sanctioned mechanism is URL-mode elicitation, which has a documented phishing attack you must defend against by verifying the browser session’s subject matches the one that triggered it.

Reachability is not solved and is the actual wall. Home Assistant’s own docs: for a cloud-hosted client, “your Home Assistant instance must be publicly accessible from the internet.” Anthropic says the same of any remote MCP server. Almost no home user can satisfy that. The honest answers are a tunnel the user runs (cloudflared, Tailscale) or a small outbound-dialling runner you ship — GitHub Actions solves the identical problem with a 50-second long poll, and that is the pattern to copy.

The order to do it in

Now, while there is exactly one user. Put an owner column on every row that belongs to a person and route every read through one accessor that demands it. This is days of work today and the source of leaks if left until there are ten; Dify was still shipping tenant-isolation fixes years in. It is the one piece of multi-tenant work worth doing before you have tenants.

User #2: a second instance, not multi-tenancy. Its own database, its own credentials, a scripted deploy. This tells you which of your assumptions are per-instance globals before those assumptions carry weight.

Users #3–10: per-user credentials. Start with the cheapest thing that works — the user pastes their own URL and token, one encrypted column. That path works with Home Assistant today. Replace it with the OAuth flow above only when pasting a token becomes the thing people complain about.

Then NAT, once. Tell users to run a tunnel first. Build your own runner only when a customer’s data genuinely cannot leave their network.

Then isolation and quota, before user #30. User-authored execution out of the main process, and spend attributed per tenant before you need to bill.

Real multi-tenancy — a user table, per-user OAuth to third parties, quotas — is a rewrite of the authority model, not a feature. Do not start here.

Running agents on another machine

The queue already claims with FOR UPDATE SKIP LOCKED, and two workers racing three sessions each took a different one with the third left queued. A second Glion on the same Postgres already shares load safely. What is missing is runner identity and a way to pin a session to a particular runner.

That gets you a second machine on your own network. It does not get you a runner behind someone else’s NAT, because it needs the database. For that, the runner has to dial out and long-poll instead — which is the same piece of work as the tunnel decision above, and should be done once.