We’re building Ever Works in public. Some things may be incomplete, missing, or broken while we continue improving the platform.We’re building Ever Works in public — expect a few rough edges.
Product
Ever Works is AGPLv3 and self-hostable in full: no part of the platform requires the hosted service. The same four container images that run the managed deployment are published to a public registry, and the Kubernetes manifests that deploy them live in the open-source repository. Run it on one server, on a cluster, or — in early access — on a single desktop machine, and enroll your own hardware as capacity.
Four application containers — dashboard, API, MCP server and docs — plus Postgres and Redis. How you host them is up to you.
Five layered Compose files ship at the repository root: a one-command SQLite demo, an infra-only file with Postgres and Redis for local development, the full stack from prebuilt images, a build-from-source variant, and an optional Trigger.dev profile.
Plain manifests for dev, stage and prod — the ones the platform is genuinely deployed with — plus the MCP server’s own. The prod manifest runs non-root with every capability dropped, and its rolling update keeps the old pod serving if the new one fails. Apply them with your own hostnames and pinned image tags.
Clone github.com/ever-works/ever-works, install with pnpm on Node 22 or newer, build the workspace packages, and run the API on port 3100 and the dashboard on 3000. Every app in the monorepo is yours to read and change.
Ever Works Desktop runs the API, the dashboard, the job runtime and a database on one machine. CI builds Windows, macOS and Linux installers as workflow artifacts; there is no public download page yet.
npm install -g ever-works-node turns a laptop, workstation or server into an execution node for your agents. Enrollment is outbound-only — the node calls the platform, nothing connects in, and no port is opened.
The shortest path from a clone to a working dashboard on your own host.
Clone the repository, then set AUTH_SECRET (at least 32 characters) and PLATFORM_ENCRYPTION_KEY (exactly 32 bytes) in the env file. The API checks both at boot and will not start without them.
docker compose -f docker-compose.demo.yml --env-file .env.demo.compose up -d evaluates on SQLite with no other infrastructure. Plain docker compose up -d runs the full stack from the published images, with Postgres 17 and Redis 7 included.
curl http://localhost:3100/api/health/ready reports which integrations are configured. The dashboard is on port 3000, the MCP server on 3200 and the docs on 3300.
Add at least one AI provider key — in the env file or under Settings → Plugins — and create your first Work. Before exposing the host, put your own TLS terminator in front of ports 3000 and 3100.
A self-hosted install is configured with environment variables and plugins, not a support ticket. These are the decisions that stay on your side.
Point the platform at the bundled Postgres container or a managed instance with an env-file edit rather than a YAML fork. SQLite is there for the one-command demo.
Trigger.dev is the default engine. The runtime seam is also built for pg-boss and BullMQ on the Postgres and Redis you already run, Temporal, Inngest and your own Fleet nodes — the non-default engines are still marked experimental.
Uploads go to local disk, AWS S3, MinIO or a GitHub repository. Knowledge Base embeddings live in pgvector inside your own Postgres by default, or in a Qdrant cluster.
Bring any AI provider through plugins, including local runtimes such as Ollama, LM Studio and vLLM. Runs on your own model keys cost no credits.
The images are public on ghcr.io/ever-works and mirrored to Docker Hub as everco/ever-works-*, with release version tags you can pin so an upgrade happens when you choose it.
Anonymous usage statistics are off on a self-hosted install unless you opt in with EVER_STATS_ENABLED=true — and once on, Settings → Ever Platform shows every byte that was sent.
Self-hosting is a first-class path, and the documentation is specific about where the work is still yours to do. None of these block a production install; each one is a decision you make deliberately rather than discover later.