The OpenCompany self-hosted image ships without a browser or a git

The default image has neither a browser nor a git

The self-hosted compose file builds from docker/Dockerfile and passes exactly one build argument, and the argument is empty:

      args:
        # Optional tools, space separated; the default image has none
        EXTRAS: ""

The comments above it name what the extras buy. browser adds Chromium and uv for the native Browser node. git adds git itself, for the Claude Code and Codex agent nodes. Everything else in the file is unconditional.

That matters because the employee catalogue is built out of exactly the capabilities the default image omits. The Researcher is described as a scout with a browser and search plus a librarian who indexes. The Builder writes and runs code, keeps dev servers alive, opens pull requests and deploys, with a release specialist holding GitHub, Vercel, Cloudflare and Google Cloud access. The Grower publishes to X, WhatsApp channels, Telegram and Discord. None of those roles has the tools it is described in terms of until you rebuild with extras, and the file's own comment tells you the rebuild command rather than warning you that the roles are inert.

The workflow engine runs in dev mode and needs two minutes to stop

Two compose settings describe what happens when the container starts and stops. The first is init: true, with a comment explaining that Docker's init reaps the processes the backend spawns: a Temporal dev server, a bun code sidecar and plugin daemons. A development server inside a self-hosted container is the phrase to notice there. The second is a stop grace period:

    ports:
      - "127.0.0.1:5678:5678"
    volumes:
      - data:/data
    restart: unless-stopped
    stop_grace_period: 120s

The comment on that grace period says the room exists so the backend can drain its workers and record a clean shutdown, and that a hard kill before it happens makes the next start pause every running deployment. All the state lives in one named volume, so the data survives; what does not survive is the in-flight work, and it comes back paused rather than resumed.

That is an unusual default for something that runs unattended. It is also why the restart policy is paired with the grace period rather than replacing it: unless-stopped brings the container back, but it cannot undo a kill that cut the drain short.

One application, two command names, two manifests at the same version

The Python supervisor is published under a new name and its old name at once. The project manifest defines company as the entry point and then adds machina as the same entry point, with a comment calling it a deprecated compatibility alias that is kept so existing automation keeps working. The npm manifest does the same thing in JavaScript form, mapping company to one script in bin/ and machina to another.

So the deprecation is real and the old name is still installed. Nobody announcing a rename tells you which of your scripts will keep running; you find it by reading a comment inside a Python manifest.

The version story is compressed in the same place. Both manifests sit at 0.2.1, matching the newest release tag. The two releases before it, v0.2.0 and v0.2.1, were both published on 2026-09-12 about six hours apart, and the one before those is v0.0.95 from 2026-07-16. So the line skipped from a 0.0.x series to a 0.2 series in a single day, and the last three tags describe roughly one day of work.

The npm scripts call python on a manifest that declares only bun

The package manifest declares one engine requirement, bun at 1.4.0 or later, and names bun as its package manager. Its scripts then shell out to a Python interpreter:

  "scripts": {
    "start": "python -m cli start",
    "dev": "python -m cli dev",

The Python side of the project requires 3.12 or later and brings its own dependency set, five packages plus a Windows-only one, declared in a separate manifest under a different project name for the CLI. Nothing in the JavaScript manifest mentions Python at all.

That split is why the terminal installer exists the way it does. The script installs bun, Python and uv when they are missing, and only then installs the npm package. A contributor following the from-source path is told the same two requirements, bun 1.4 or later and Python 3.12, in a sentence rather than in a manifest that could be checked. There is also a manifest setting that tells uv to keep its hands off this project, so that the supervisor runs against the interpreter already on your path instead of a workspace environment that shadows it; the server is the one part of the repository that does get a managed environment.

The published package ships the env template but not the setup guide

The npm manifest carries an explicit allowlist of what goes into the tarball, and it is a long one: the bin directory, the scripts directory, the bundled workflows, the CLI, the client's sources and build output, the server, the environment template, the Python manifest, the readme and the two install scripts.

Docs are not on that list, and the readme's own instructions lean on them. The terminal path points at a setup file, the container path points at a Docker guide, and the contributor path points at all three plus the contributing guide. None of those directories appears in the published file list, so a person who installed the package from a registry is one click away from a file they do not have, and the only place to get it is the source repository.

The same allowlist draws a useful line around the environment files. The root holds three of them, a plain one, a development one and a template. The template is published. The other two are not on the list, and neither is a directory of test fixtures the manifest excludes by name.

Both installs want port 5678, and one of them pipes a script into your shell

The terminal install is two lines and a start command:

curl -fsSL https://opencompany.sh/install.sh | bash    # macOS / Linux
company start

The Windows variant pipes a PowerShell script into the interpreter the same way. In both cases the script's privileges are the shell's, and its contents are whatever the server serves at that moment.

The port is the smaller problem but the more likely one. The terminal path ends by telling you to open http://localhost:5678, and the container path ends by telling you to open http://localhost:5678 and register the owner account. Data for the terminal install lives in a hidden directory in your home folder and is shared with the desktop app, so the desktop app, the terminal install and the container are three ways to reach the same interface and any two of them collide on the same port.

The container publishes its port on one address only, bound to the loopback interface on the host, and the compose comment says that serving other hosts means dropping that prefix and putting TLS in front.

The builds are unsigned and the guide tells you which warning to dismiss

The quick start offers five downloads, all pointing at the latest release: a Windows executable, two macOS disk images split by processor generation, and a Linux AppImage with a Debian package for Debian and Ubuntu. There is no build for a phone, even though the package keywords list android among the things this software is.

Then there is the signing paragraph, which is unusually direct. The builds are not code-signed yet. On macOS the system asks you to allow the app under Privacy and Security in System Settings. On Windows, SmartScreen needs you to choose More info and then Run anyway.

That is a reasonable thing for a project to say outright, and it still leaves the reader doing the dismissing. An unsigned binary plus a shell that executes whatever a URL returns is the whole trust chain, and both halves of it are opt-in clicks. Anyone deploying this for a team should decide in advance who is allowed to make those clicks, because the answer is otherwise made per machine, quietly, by whoever installs it first.

Three RFCs at the root, and an employee list that stops mid-sentence

The design bets are written down as numbered documents rather than left in chat: a universal API schema translation layer, an agent context and memory proposal, and an OpenAI-compatible provider contract. Three architecture decisions, argued in the open, in a repository that also ships a commercial-looking desktop app.

The rest of the root is less tidy. Alongside the environment files and the ignore files there are an import data file, an output directory, a directory holding the bundled workflows, and an uninstall script. The client, desktop, server, CLI, scripts and docker directories sit next to each other with no explanation in the root of which one is the product and which are build machinery, and the workspace list in the JavaScript manifest points at a Node subdirectory inside the server while the Python manifest says the server is the one part with a managed environment.

The catalogue of employees is the other boundary. Builder, Grower, Chief of Staff, Front Desk and Researcher are each described with their team composition. The sixth entry, Treasurer, begins with one line and stops after the word handle.

Editorial conclusion

OpenCompany is worth trying on a machine you own, where the desktop app and your own API keys are the point, and worth reading as a design document even if you never install it, since the three RFC files at its root say more about its direction than the marketing line about self-improving employees does. Four things to check first. Know that the default container contains neither a browser nor git, so the Researcher, Builder and Grower roles depend on build extras you have to ask for explicitly. Give it a graceful stop, because the orchestration engine needs a couple of minutes to drain and a hard kill leaves every running deployment paused on the next start. Read the trust chain before you run anything: the desktop builds are not code-signed and the terminal path pipes a remote script into your shell. And decide about the naming, because a command from the project's earlier identity is still installed alongside the current one for the benefit of somebody's existing automation. If you need audited releases with signed artifacts, the release history here is three tags, two of them published on the same day.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. zeenie-ai/OpenCompany on GitHub