Loams Software Factory

What it isCopy Anchor Link

Loams Software Factory is two things, and only the first one ships.

The first is a toolchain you run yourself, seen from one place. A team that builds software needs a code host with CI, a chat, an issue tracker, error tracking, analytics, LLM traces and logs. The factory picks open-source apps for each of those jobs and puts them inside Loams Desktop: each app gets read-only native panels (open pull requests, unresolved errors, recent traces) and its own full web UI in an isolated view, under the Factory group of Loams Studio. Loams does not fork, patch or host these apps. You run them, and you give Loams Desktop a URL and a token for each.

The second is the factory loop: a durable workflow in which a signal (an error, an analytics anomaly, a request in chat) becomes a triage thread, an issue, a branch, a pull request with green CI, a merge a person approves, a deploy and an observation window, with agents doing the work between the gates. That loop is designed (§39) and planned (SF2 to SF5). It is not built.

Use the factory today if you already run some of these apps, or want to, and would like them next to your coding agents in Studio: a Plane issue or a GlitchTip error becomes the starting draft of a Studio thread, and a thread's branch links to its Forgejo pull request. Do not use it as an autonomous agent platform yet. Every factory panel only reads, the hand-off from an issue to a thread is copy and paste, and nothing in Loams 0.1.0 merges or deploys on its own.

StatusCopy Anchor Link

The factory is experimental in Loams 0.1.0 and lives on the desktop only. It ships inside Loams Desktop, in Studio mode, which is itself experimental.

The decisions behind the loop (D-SF-1 to D-SF-20) are recorded as proposed in the decision log. The desktop's factory rulings (D653, D659, D660, D678) are approved.

ArchitectureCopy Anchor Link

How it worksCopy Anchor Link

The appsCopy Anchor Link

The factory follows a "buy, not build" rule from the design: each job goes to an existing open-source app, run unmodified from its official image. Loams adds panels and, later, agents. It never adds a feature to the app itself.

Two names need a note. The desktop labels the planning app "Plane (ItsAPlan)": the owner ruled that the Plane-compatible product the factory means is ItsAPlan (Q622), and its adapter is what the panels call. And Matomo was not in the owner's original list; it came in with the desktop's showcase and stays in the Factory group by default (Q813).

Panels read; full UIs are isolatedCopy Anchor Link

Every panel is backed by one adapter method, and the desktop's main process only accepts operations whose names start with get, list, search, health, fetch or query, each with a strict parameter schema and a cap of 50 rows. There is no write operation in the factory panels in 0.1.0 (D660). Writes are meant to arrive with the platform agents and their approvals.

Each app also has a health state on its tile: unconfigured, ok, auth_failed or unreachable.

An app's own web UI opens inside the main window as a separate Electron view, with its own storage partition, no preload script, a sandbox and navigation locked to the app's origin; other origins open in your system browser (D678). Up to four app views stay alive for quick switching. You sign in to the app inside that view, with the app's own login, so its cookies never mix with the console's session.

Credentials stay out of the pageCopy Anchor Link

The tokens you enter are encrypted on your computer and decrypted only in the desktop's main process. They are never part of a reply to the page, and the agent transcript scrubber masks factory secrets. Where the system has no keyring backend (some Linux setups), credentials are kept for the session only, and the configure page says so. Changing an app's URL to a different origin asks for the secret again rather than sending the old token to a new host.

From an issue to a thread to a pull requestCopy Anchor Link

The factory is wired into Studio in three places:

• Plane: Start thread. On an issue, Studio's home shows a "New thread from Plane" card with the issue's key, title and priority, and a branch named after the key.
• GlitchTip: Fix this error. The card carries the latest event's stack trace (innermost frame first, up to 40 frames and 4,000 characters) and the release.
• Pull requests. When a thread's branch has an open pull request on Forgejo, Studio's git toolbar links to it, and Studio can open one for a pushed branch through loams-agentd. Forgejo has no draft flag, so a draft is titled WIP: ….

The card does not fill the composer yet: you copy the draft into a project's New thread. Posting a result back to Zulip is not built, because it is a write that needs an approval.

The loop (planned)Copy Anchor Link

The design turns those hand-offs into one durable workflow per signal, factory.run, on Loams' durable execution engine. It has eight stages:

The parts that matter, from §39:

• One agent per app, each an A2A server with its own principal and a signed Agent Card: zulip, plane, forgejo, glitchtip and analytics. Coding is a skill of the Forgejo agent (propose_patch), which runs a sandboxed session on a workspace branch and turns the patch into a branch and a pull request.
• Agents never hold app credentials. A credential broker makes the app call; a destructive call must carry a settled approval that matches its hash, so an agent that has been talked out of waiting still cannot get the credential.
• Safety rails in the engine, not the prompt. Per-run and per-organisation budgets (the owner set $5 per run and $50 per organisation per day as defaults, Q471), at most three CI attempts, a kill switch per run, agent or organisation, a cap on regression generations and a cooldown per fingerprint.
• No auto-merge and no auto-deploy by default. A policy can allow them only for listed repositories or services in unprotected environments.
• Every step traced twice. Spans with model content go to Langfuse through a masking collector that fails closed; every span, log and metric without content goes to OpenObserve and to Loams' own ingest.
• A run is a record: a Live table of runs, a stream of factory events and console pages for runs, approvals, agents, budgets and the kill switch.

Set it upCopy Anchor Link

You need Loams Desktop 0.1.0 and the apps you want, already running somewhere the desktop can reach (your tailnet is a good place). Loams does not deploy the apps for you yet. Each project publishes its own self-hosting guide; start with the Forgejo installation docs, Zulip's self-hosting guide and Plane's Docker Compose guide.

Give each token the least it needs. The panels only read, so a read-only token is enough for every app except Forgejo, where Studio's pull requests need a token that can open them.

LimitsCopy Anchor Link

• Desktop only. The browser console has no Factory group until SF1 lands (D922); phones have nothing yet.
• Read-only panels. No comment, create, resolve or merge from a panel.
• No loop, no agents, no Loams Bot chat over the apps. The hand-off from an issue to a thread is manual.
• You operate the apps. Their upgrades, backups, sign-in and security are yours; Loams pins nothing for them yet.
• One app, one account. The desktop holds one credential per app, so the panels show what that account can see.

Compared withCopy Anchor Link

GitLab is the honest alternative for a team that wants one self-hosted application instead of eight; its own docs set a baseline of 8 vCPU and 16 GB of memory for a single node. The factory's bet is that several smaller, single-purpose apps, each the best open-source option for its job, are easier to swap and to run in pieces, with Loams as the glue. The cost is more services to operate, which the planned Helm package is meant to reduce.

DecisionsCopy Anchor Link

• D-SF-1 (proposed): two products, one loop. The factory is the loop; Loams Bot is the chat that drives it. Phase 1 is Zulip, Plane and Forgejo; phase 2 adds GlitchTip, OpenPanel, Langfuse and OpenObserve.
• D-SF-14 (proposed): rails in the engine. Budgets, a kill switch, loop limits and no auto-merge or auto-deploy by default.
• D-SF-16 (proposed, superseded in part by D1119): all open source. The agents, plugins, the loop and a single-organisation factory you can self-host are open source, and since D1119 (2026-10-19) so is the hosted multi-tenant factory; Loams has no open core.
• D-SF-17 (proposed): unmodified apps from official images, pinned by digest.
• D653, D660, D678 (approved): the desktop's factory. Eight apps as read-only panels and embedded full UIs, with OpenObserve full-UI only.
• D916 and D922 (proposed, built as amended): the factory moves under Studio, and stays desktop-only until SF1.

Further readingCopy Anchor Link

• Design: §39 Loams Software Factory and Loams Bot, §37 §19 Loams Desktop on Electron, §53 Loams Studio
• Plans: SF1 collaboration UIs, SF4 the factory loop, SF5 observability UIs
• Guide: The factory in Studio
• Related: Loams Studio, Loams Git, Loams Desktop and the loams CLI
• Blog: A software factory you own