Arkloop: a local-first AI agent platform with an embedded Go runtime

What Arkloop is for, and who it leaves out

Arkloop is a personal, open source platform for conversational AI agents that runs on your own computer. The README frames it as local-first: the backend is a single embedded process with a SQLite database, and the project states there are no servers to deploy and no infrastructure to maintain. That framing is the product decision. Most agent platforms assume you will run a service somewhere and connect a client to it; Arkloop assumes the client and the service are the same machine.

The intended user is one person with several model API keys who wants chat, tool calling, code execution and memory in one place. The feature list covers multi-model routing across OpenAI, Anthropic, Gemini and any OpenAI-compatible API with priority-based routing and your own keys; an agent runtime with built-in tools, MCP servers and ClawHub skills, plus sub-agent spawning and scheduled jobs; memory that defaults to a plain-text notebook with an optional Nowledge semantic layer and can be switched off; channels for Telegram, Discord, QQ, Feishu and WeChat bots that share the same agent pipeline; and custom personas with independent system prompts, tool allowlists, budgets and executor types.

Who it leaves out matters as much. The README does not describe team accounts, shared workspaces or a hosted control plane. Nothing in the repository suggests Arkloop is meant to be embedded in someone else's product. The licence reinforces that reading, and the multi-tenant restriction is discussed below.

One Go process, SQLite, and where the desktop app sits

The architecture table in the README is short and worth reading literally. The Desktop layer is Electron, described as a native shell embedding the Go runtime. The Runtime layer is Go, described as a single process containing API and worker, with SQLite and an in-process event bus. The Web layer is React and TypeScript, a chat UI bundled into the desktop app and also served by `ark web`. The CLI layer is Go, the `ark` binary, described as a headless entrypoint to the same runtime.

So there is one runtime, and three ways to reach it: the Electron window, the web UI served locally, or the CLI. The desktop app is not a separate implementation. It embeds the same Go process that `ark web` starts. That is why the README can say the desktop build bundles the full runtime and needs no Docker.

The storage story is equally concrete. The README says storage is a local SQLite database, auto-migrated on first start, plus the filesystem, with no Postgres, Redis or message queue. The `.env.example` file names the storage backend explicitly: `ARKLOOP_STORAGE_BACKEND=filesystem` with `ARKLOOP_STORAGE_ROOT=/var/lib/arkloop/storage`, and comments that this default suits single-node self-hosting. The Makefile confirms the split from the build side: the desktop target builds the worker with a `desktop` build tag, and the comment says that build excludes Redis, PostgreSQL and S3 SDK dependencies. The cloud build is what carries those dependencies.

That is the trade-off in one line. You get a backend with no external services, and in exchange the runtime is tied to one machine and one SQLite file. The README does not document a supported way to run several nodes against shared state.

Installing Arkloop and running your first headless session

The README points first at GitHub Releases, with builds for macOS, Linux and Windows. The desktop app bundles the full runtime, so the shortest path is to download the installer for your platform, open it, and use the app. Automatic updates come through GitHub Releases.

The README states that on first launch the desktop app can install the `ark` command-line tool. Once that is done, you can start the same local runtime without the desktop window:

ark web

If you prefer a package manager, Homebrew installs the CLI only, not the desktop app:

brew install qqqqqf-q/arkloop/arkloop && ark web

On Arch Linux the README lists two AUR packages, one prebuilt and one built from source:

yay -S arkloop-bin    # prebuilt binary
yay -S arkloop-git    # build from source

For a headless Linux machine the README gives a single command that detects the architecture, downloads the matching release tarball, and starts the runtime bound to all interfaces with the browser launch suppressed:

sh -c 'set -e; arch="$(uname -m)"; case "$arch" in x86_64|amd64) arch=amd64 ;; aarch64|arm64) arch=arm64 ;; *) echo "unsupported architecture: $arch" >&2; exit 1 ;; esac; name="ark-linux-${arch}"; rm -rf "$name"; curl -fsSL "https://github.com/qqqqqf-q/Arkloop/releases/latest/download/${name}.tar.gz" | tar -xz; cd "$name"; exec ./ark web --host 0.0.0.0 --no-open'

Note the two flags in that last command. `--host 0.0.0.0` binds the local API and web UI to every interface, which is what makes a remote machine reachable and also what makes it reachable by anything else on the network. `--no-open` stops the runtime from opening a browser, which is the right choice on a server. The README does not describe authentication for that exposed port, so treat the binding as a network decision rather than a convenience flag.

Building from source is documented separately. The root package.json is private and pins `[email protected]`, and the README gives this sequence, including a headless run from source:

pnpm install
cd src/apps/desktop && pnpm dev        # Desktop app (Electron + embedded runtime)

# Headless, from source:
cd src/apps/web && pnpm build
go run ./src/services/cli/cmd/ark web  # Serves the web UI and local API

There is also a local CI entry point, `bin/ci-local quick`, and the Makefile exposes `make test`, which runs the desktop-tagged suite. What you should see after `ark web` is the chat UI served locally, backed by the same runtime the desktop app uses. Configure your model provider keys inside the app or through the environment; the `.env.example` lists `ARKLOOP_AUTH_JWT_SECRET`, `ARKLOOP_ENCRYPTION_KEY` and `ARKLOOP_API_PORT=19001` among its keys, and comments that API keys and secrets are stored encrypted with AES-256-GCM using a 64-hex-character key generated by `openssl rand -hex 32`.

The single-process design is also the main limitation

The README presents the embedded runtime as a benefit, and for a personal install it is. The same property is a hard boundary. If the process stops, the agent stops; there is no worker fleet to absorb the load and no queue to hold work while a machine restarts. The README's own description of the runtime as one process containing API and worker, with an in-process event bus, leaves nothing to fail over to.

Concurrency is bounded per organisation. The `.env.example` documents `ARKLOOP_LIMIT_CONCURRENT_RUNS` with a default of 10, described as the maximum concurrent runs per org. On a single-user install that ceiling is unlikely to matter; on a machine shared by several people it will.

Storage is the second boundary. The documented backend is filesystem with a root directory, and the database is SQLite. Nothing in the repository describes replication, a managed database option, or a migration path to one. The Makefile shows that the cloud build exists and pulls in Redis, PostgreSQL and S3 SDK dependencies, but the README does not document how to run that configuration. If you need multiple nodes sharing state, the documentation does not tell you how, and you should not assume the desktop build scales sideways.

The third gap is operational documentation. The README does not document rollback, backup or restore for the SQLite database or the storage root, and it does not describe what happens to in-flight runs during an upgrade. The `.env.example` mentions a debug switch for LLM raw input and output written to run events, flagged as local-development-only, and a structured SSE stream log for tracking unexpected EOFs aligned by trace_id and run_id. Those are useful hooks, but they are debugging aids, not a monitoring story.

Arkloop compared with running your own agent stack

The obvious alternative is assembling the pieces yourself: a chat front end, a model router, a tool executor, a memory store, and one of the open agent frameworks to tie them together. That approach gives you full control over the deployment topology. You can put the agent behind a load balancer, use a managed Postgres, and scale workers independently. You also own every integration, every schema migration, and every retry policy.

Arkloop's difference is that those decisions are already made and made small. Routing across providers with priority ordering, MCP server support, sub-agent spawning, scheduled jobs, channel bots and personas are one installable runtime rather than a set of libraries you wire together. The cost is that you inherit its choices: one process, one SQLite file, a filesystem storage root, and a concurrency cap that defaults to 10 runs per org.

A second alternative is a hosted agent product. There, the runtime is someone else's machine, and your model keys and conversation history live behind their API. Arkloop is positioned against that: everything runs locally, and the keys are yours. The trade is that availability, backups and upgrades become your problem, and the repository does not provide tooling for them.

A third comparison is worth making because the README makes it implicitly. Arkloop says it does what other AI chat tools do, listing multi-model support, tool calling, code execution and memory, and says the focus is on doing it cleanly. If your requirement is a chat client for a single model, the runtime, the personas and the channel bots are weight you will not use.

Licence terms, upgrade cost and what to check before relying on it

Arkloop is released under the Arkloop License, which the README describes as a modified Apache License 2.0 with two additional conditions. The first is a multi-tenant restriction: the source code may not be used to operate a multi-tenant SaaS without written authorization. The second is brand protection: the LOGO and copyright information in the frontend components must not be removed or modified.

Both conditions sit outside the plain Apache 2.0 grant, so the summary in the README is not a substitute for the LICENSE file. If you plan to fork the frontend, white-label the UI, or host it for other people, read the actual licence text and the NOTICE file before you build anything on it. This is a description of what the repository states, not legal advice.

The project describes itself as a personal open source project, and the sponsor list in the README supports that reading: it thanks individuals for a domain, an iced Americano, and two weeks of AI costs. That is a small-project funding model, and it is the honest context for judging support expectations.

On upgrade cost, the desktop app updates through GitHub Releases, which the README calls out explicitly. The CLI installed through Homebrew or the AUR follows those channels instead. The schema is auto-migrated on first start, so a new version may change your local database without a separate migration step; the README does not document a downgrade path, so keeping a copy of the SQLite file and the storage root before an upgrade is the only rollback the documentation supports. The latest release listed is v26.5.21.2 from 2026-05-21, and the last push to the repository was on 2026-08-27.

Editorial conclusion

Adopt Arkloop if you want a single-user agent runtime on your own machine, with your own model keys and no Postgres, Redis or queue to operate. Do not adopt it if you intend to run a multi-tenant SaaS on the source, or if you need a documented multi-node deployment: the README describes one embedded process with a local SQLite database, and the .env.example storage backend is filesystem. Before committing, verify the exact terms in LICENSE rather than the summary in the README, check that the persona, MCP and channel features you depend on are covered by the test-desktop package list, and confirm the release artefacts for your platform exist on the releases page. The one thing to decide first is whether your workload fits a single machine.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. qqqqqf-q/Arkloop on GitHub
4. README
5. Releases