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.
Run anywhere · Where things run
Four separate questions hide inside the word “deploy”: where a Work’s website goes live, where Ever Works itself runs, what executes the background jobs behind your agents, and where your files, databases and embeddings end up. Each one is a plugin socket rather than a hardcoded answer — so you can put the site on someone else’s platform and the runtime on your own hardware, or the other way round, without rewriting anything.
Pick the target at onboarding Step 5 — Your deployment, or later on the Work’s Deploy tab. Domains and database configuration are stored on the platform rather than at the provider, so switching targets re-syncs them instead of losing them.
The zero-infrastructure path: no kubeconfig to paste, no registry to wire, no DNS zone to own. The platform supplies a namespace on its shared customer cluster, a public address at <slug>.ever.works with the DNS record already behind it, and a PostgreSQL database provisioned for that Work. Active managed Works are capped per account — three by default on the hosted platform, and the check runs before anything is provisioned, so you are told at creation rather than mid-deploy. The shared cluster is still being brought up environment by environment — where it is not ready, a deploy fails with a plain “not yet available” message rather than quietly landing somewhere else.
Paste your own Vercel API token in Settings → Plugins → Deployment; it is verified against Vercel on save, before any deploy depends on it. Deploying pushes the generated site to its GitHub repository and triggers a Vercel build through a GitHub Actions workflow, and Vercel serves the result from its global CDN with HTTPS already on.
Paste a kubeconfig for any cluster on 1.27 or newer — EKS, GKE, AKS, k3s, on-prem — and Ever Works probes it on save, reporting back the cluster name, the server version and every IngressClass it found. Each deploy is a server-side apply of a Deployment, a Service and, where you have a controller, an Ingress: nginx and Traefik get their own annotations, cert-manager issues the certificates, and images go to GitHub Container Registry by default, Docker Hub, or any OCI registry you hand credentials.
On Work → Deploy, type a hostname and the platform stores it, pushes it to the provider, and shows the exact CNAME or A record to create with a Copy button on each field. Press Verify DNS and a live lookup either flips the row to Verified — promoting the domain to the Work’s primary URL when the old one was provider-assigned — or tells you what is still wrong. Configure the Cloudflare DNS plugin with your own token and zone id and the record is written for you.
The same four applications — API, dashboard, MCP server and docs — however you choose to host them. Most of what is below is a published artifact you can pull today rather than a plan behind a sales call — the exception is Desktop, still early access, whose installers exist only as CI workflow artifacts.
Sign in and start building. Background workers, the database and the deploy pipeline are operated for you, and each managed piece — hosting, the Ever Works database, DNS — is independently available, so you can adopt them one at a time rather than all at once.
Five layered Compose files ship at the repository root: a SQLite demo that runs with one command, an infra-only file that starts just Postgres and Redis for local development, the full stack from prebuilt images, a build-from-source variant, and a profile-gated self-hosted Trigger.dev. The images are public — ghcr.io/ever-works/ever-works-web, -api, -mcp and -docs — and they land in that order on the dashboard at 3000, the API at 3100, the MCP server at 3200 and the docs at 3300.
The repository carries the manifests the platform is genuinely deployed with: dev, stage and prod for the main stack, plus three more for the MCP server. The operations guide covers health checks, scaling policy, secrets and the ingress in front of it. There is no Helm chart yet — you apply the manifests and pin your own image tags.
Ever Works Desktop runs the API, the dashboard, the job runtime and a database on one machine. It is early access: CI packages Windows, macOS and Linux installers as workflow artifacts, and there is no public download page yet. Enrolling execution nodes is further along — ever-works-node joins any machine to your fleet over an outbound-only channel, with nothing exposed to the internet.
Agent heartbeats, generation pipelines, scheduled updates, embedding and webhook delivery never import a vendor SDK at the call site. They go through eleven dispatcher symbols that a registry binds to one runtime plugin, and it is that seam which has shipped: six runtime packages, an EVER_WORKS_JOB_RUNTIME selector validated and logged at boot, and the per-tenant overlay at Settings → Job Runtime with its audit trail and operator allow-lists. The selection moves the Agent-run and Fleet dispatch path today, and the Desktop build reads it too; the eleven queue dispatchers still resolve to the Trigger.dev provider, because that is the only provider the bundled build registers, until an operator registers another. So read the six below as the engines the seam was built for rather than as six switches already live on a settings page.
The default and the zero-config path: set a secret key and a project ref and background work runs. Use Trigger.dev Cloud, or point the API URL at your own instance — a Compose profile brings the self-hosted webapp up next to the platform.
The “just Postgres” answer. Queues live in a schema on a database you already run, so a complete self-hosted Ever Works needs no Redis and no external service at all. Point it at the platform’s own connection string and there is nothing new to operate.
Redis-backed queues inside your own deployment, configured with a Redis URL and an optional queue prefix. The right pick when Redis is already in your stack and you want the queue somewhere you can inspect it.
The durable-workflow option for teams already running a Temporal Service, and the strongest of the six at multi-hour runs. Self-host the MIT-licensed server or use Temporal Cloud — the mTLS certificate pair is a first-class setting.
Hosted, event-driven execution behind an event key and a signing key. It is cloud-only deliberately: the plugin ships no self-host path, so pick Temporal, BullMQ or pg-boss when you want a runtime you own end to end.
Your own enrolled machines lease jobs and post the verdict back over the same outbound-only channel they heartbeat on. Nothing connects in to your hardware and no port is opened, so capacity grows by adding a laptop rather than by resizing a plan.
The other half of “where does it run” is “where does it land”. Each of these is chosen once and applies everywhere the platform writes.
One backend handles every byte that enters the platform — Knowledge Base originals, prompt attachments, Memory files, agent avatars — and it is local disk, AWS S3, MinIO, or a GitHub repository with optional Git LFS. Every byte that goes through the API upload route is validated the same way on all four: the declared content type is checked against real magic bytes, SVG is rejected outright, size caps apply, and the storage key is the file’s own SHA-256, so a client-supplied filename never reaches your disk or bucket. One exception, worth knowing before you point a public form at it: S3 and MinIO also offer an optional presigned upload that goes straight to the bucket, and those bytes never pass through the API — no magic-byte sniff, no MIME allow-list, no size cap beyond a 2 GiB body limit, and a random key instead of a content-addressed one. Keep untrusted uploads on the API route.
A live site needs somewhere to keep logins, submissions and favourites, so every deployed Work gets a PostgreSQL database of its own — on the managed Ever Works cluster, on a server you supply once for all your Works, or overridden for a single Work on its Deploy tab. Provisioning is idempotent and keyed on the Work id, and the Test button opens a real connection before you commit a connection string.
Knowledge Base embeddings default to pgvector inside the API’s own Postgres, with every query row-filtered by Work, so there is nothing extra to run. Install the Qdrant plugin from the registry and switch at Settings → Plugins → Vector Stores to move a Work’s embeddings onto a managed or self-hosted Qdrant cluster with one collection per Work.
Data Management exports your whole account — Works, items, comparisons, schedules, prompts, plugin settings and profile — as a versioned JSON file, with real secret values never included. Import is preview-then-apply, offering skip, overwrite or rename on each conflicting Work, and GitHub Sync keeps a private repository as a continuous backup.
Everything above is a target you can select today. Here is the other side of the list, because a deploy page that implies more than exists is how people find out at the worst possible moment. Two deployment plugins exist for Works — Vercel and Kubernetes — alongside the platform-managed Ever Works provider. That is the whole list.
Ship to Ever Works managed hosting, Vercel, or your own Kubernetes cluster — with one config, every time.
Learn more →Run Ever Works in the cloud, self-host the platform with Docker Compose or Kubernetes manifests, and deploy your Works to Ever Works hosting, Vercel, or your own cluster.
Learn more →Your domain, your brand, on every Work — with HTTPS, redirects, and DNS handled for you.
Learn more →Turn any machine into an execution node with Ever Works Node, and see every node — including your own Kubernetes nodes — in one Fleet view.
Learn more →Run the entire Ever Works stack on your own machine — API, dashboard, jobs runtime, and database in one app. Early access: build it from source, or take an installer a CI run produced.
Learn more →Named runtime sandboxes you assign per Agent, credentials resolved from your own secret store, and a registry of the external MCP servers and repositories your agents may reach.
Learn more →A plugin is a capability the platform does not have on its own — a model, a search engine, a Git host, a deploy target — and Ever Works ships 102 of them.
Learn more →Describe what you want to build. Ever Works researches it, ships it, and keeps it improving — content and code, owned in your own Git.