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.
FAQ
Ever Works is an open agentic runtime that researches, ships and maintains content-rich websites and Git repositories. These are the questions people ask before they start — what it builds today, what it does not build yet, who owns the output, how much autonomy the AI actually has, and what it costs.
Ever Works is the workshop for AI: an open agentic runtime that autonomously researches, ships and maintains content-rich websites and Git repositories. It fuses the builder experience — describe what you want, get a working site — with a 24/7 AI workforce that keeps writing, researching and improving long after the first build. Content and code both land in Git repositories you own, and the platform itself is open source under AGPLv3.
A Mission is an ongoing goal the platform keeps pursuing — "run the best cat-toys business worldwide". An Idea is a single one-shot proposal, and one Idea becomes one Work. A Work is the buildable, self-maintaining unit: the website, blog or directory that actually goes live. Agents are your named AI employees — a CEO, a Researcher, a Reviewer — that run the Missions, Ideas and Works when you are not watching.
Six kinds of Work sit on the create screen. Five of them generate a site — website, landing page, blog, directory and awesome repo — each starting from a prebuilt template (a Next.js one or a static Astro one) you can fork into your own GitHub account or swap for a template repository of your own. The sixth, Repository, generates nothing: it registers an existing code repository as a Work so Tasks, Goals and fleet runs attach to it. Two further kinds are minted by dedicated flows rather than the create screen: company, through the Register Company dialog, and campaign, through go-to-market template activation. All five generated kinds are wired end to end, but the content generator behind them is not equally deep yet — see the next answer.
There is no generic “app” Work kind — the five generated kinds on the create screen are website, landing page, blog, directory and awesome repo. But what they produce is a real application rather than a page export. A directory or awesome-repo Work is built from the classic template: a Next.js 16 App Router monorepo in TypeScript, with sign-in through Auth.js or Supabase Auth across five OAuth providers, Drizzle over Supabase, PostgreSQL, MySQL or SQLite, payments through Stripe, Lemon Squeezy, Polar or Solidgate, visitor submissions with moderation and a full admin panel, search and filters, 21 languages, SEO with sitemap, robots and structured data, RSS, Atom and JSON feeds, and a Playwright end-to-end suite. A website, landing-page or blog Work starts from the general web template instead — an App Router marketing site with hero, features, pricing and FAQ sections, About / Pricing / Contact pages and a Markdown blog, with no item lists, faceted filters or directory data model — which you extend in your own repository; dedicated blog-post and landing-copy generators are still rolling out. Either way it is not an app you describe in the abstract, but an application codebase you own and keep building on.
All five generated kinds are wired end to end — the chip, the persisted kind, the per-kind tabs and Overview tiles, the works.yml spec, the deploy and the schedule. The content generator behind them is one shared pipeline, and it was built for directory-shaped content first: it writes items and their markdown, categories, tags, collections, cited references and comparisons. So a Blog Work’s Posts tab and a Website Work’s Pages tab are filled by that same pipeline, a Landing Page Work’s sections come from the general Website template, and dedicated blog-post and landing-copy generators are rolling out. Everything around the words works for those kinds today: the Git repositories, the deploy, the custom domain, the Knowledge Base and the schedule that keeps re-running.
Stores are the honest gap: the Store chip is on the create surface, but the storefront generator and the commerce integrations are still roadmap work. The blog, website and landing-page kinds are wired end to end, but their content still comes from the shared items pipeline — dedicated blog-post and landing-copy generators are rolling out. Company registration ships as a v1 manual record — it creates a real Organization with the registration metadata preserved, but nothing is filed with a registrar, and incorporation through a formation provider is planned. The Desktop App is built and tested in the monorepo, and CI packages Windows, macOS and Linux installers on every relevant push, but there is no public download yet.
Every Work gets three Git repositories that you own: one for structured item data, one for the rendered markdown, and one for the deployable website. They are created in your own GitHub account or organization, or in the managed Ever Works Git organization if you keep the onboarding default. Leaving is a non-event: you keep all three repositories, and the Knowledge Base leaves with them, because it is stored as plain markdown under .content/kb/ in the data repository. There is nothing to export, because nothing was ever only in the platform.
AGPLv3, across the whole monorepo — the API, the dashboard, the MCP server, the CLI, the desktop app and the plugin catalog. The Community Edition is a free download with no seat limit and no license fee. The paid self-hosted editions are commercial licenses that lift the AGPLv3 obligations, for companies that cannot comply with them.
In full — no part of the platform requires the hosted service, and the same container images that run the managed deployment are published publicly. There are five layered Docker Compose files at the repository root, from a SQLite demo up to a Postgres and Redis stack, plus plain Kubernetes manifests for three environments. (There is no Helm chart; copy the manifests.) You can also enroll your own machines as Fleet execution nodes, so the agent runs themselves happen on hardware you control.
No. Type a prompt on this site and you land on the onboarding page with a temporary guest session already minted, so your first Work can be generated before you create anything. When you want to keep it, claim that session with an email address and a password — it upgrades the same account rather than starting a new one, so everything you generated stays with you. You can also sign up directly with email and password, or with GitHub, Google, Facebook or LinkedIn where your installation has them configured.
The moment you submit a prompt on this site a temporary guest session is minted, so nothing waits on a signup. Agents research the topic first — reading and scraping real sources, scoring them, and producing a brief per page — and then the code pass clones a maintained production template into a website repository in your own Git: directory and awesome-repo Works get the classic Next.js base, while website, landing-page and blog Works start on the general web base. The researched content is written into your data repository, the site is generated from it, and where you have turned them on the quality gates run and the change arrives as a pull request rather than a direct commit. Then one step needs your hands — nothing publishes itself: you deploy once from the Work’s Deploy tab, and from there the schedule you set keeps re-running the research and refresh passes without you.
Keeping the Ever Works defaults it is ten steps: your AI provider, Git storage, database, deployment target, where the platform itself runs, what you do, your chat workspace, plugins, and finally the prompt for your first Work. Every step that asks you something can be skipped, and nothing is permanent — each choice can be changed later in Settings. Your answers are saved to the server as you make them, so progress survives a reload or a new device, and picking a bring-your-own option simply adds a short configuration step right after it.
A first generation run typically takes two to five minutes, and the dashboard says so — you can close the page and come back. Deployment adds another one to three minutes, with a progress panel tracking the initializing, queued and building states. From an empty prompt to a scheduled, deployed directory, expect ten to fifteen minutes at the keyboard.
They are — within limits you set. Give an Agent a heartbeat cadence and it wakes on a schedule and picks exactly one next action: create a task, comment on an open one, edit its own instruction files to capture a learning, or observe and do nothing this tick. How far it may go on its own is a per-Agent guardrail policy, and a brand-new Agent has none, which means every action with side effects that it proposes queues for a human. Switch it to autonomous and it can self-approve unflagged actions of the types you allow; blocked types are refused in both modes, and a risk-flagged action always comes to you.
Yes — and both halves of that answer matter. A Mission can be set to auto-build Works, and then every Idea it spawns is queued into its own Work with no click from you, bounded by two limits: the per-Mission and account-wide budget caps, where a cap that is hit skips the build rather than retrying it, and the outstanding-Ideas cap — your per-Mission value, then your account default, then a platform default of 20 — which makes a tick a quiet no-op instead of flooding the queue. The honest half: none of it runs until the Work agent is switched on in Settings. That switch is off on a brand-new account and it gates both paths, the Build button you press yourself and a Mission’s auto-build alike, so a loop can look armed and never build. On managed hosting there is a second gate that is not yours — the build executor is connected by the platform operator. And the first deploy of a Work is always a human action.
Budgets are checked before an AI call runs, not after the bill arrives. You can cap spend account-wide under Settings → Account → Usage & Budget, and separately per Mission, per Idea and per Work; each Agent can also carry its own cap over an hourly, daily, weekly or monthly interval. The strictest cap that applies wins. A hard cap blocks the next call outright and records the would-have-spent amount; allow overage instead and the call proceeds while you get an alert at the percentage threshold you chose.
Three mechanisms catch it. Consecutive failures auto-pause the Agent or the schedule — three by default, and adjustable from one to twenty on an Agent, one to ten on a schedule — so a misbehaving worker cannot run away with your spend. A doom-loop detector watches the failure trail inside a run and ends the loop early when attempts keep repeating the same failure without progress, instead of paying for another one. And a run that gives up files an escalation carrying the reason, which lands in your Inbox alongside anything an Agent explicitly stopped to ask you.
Every run is a session you can open under Teams → Sessions, with a live timeline of messages, tool calls and touched files that follows the run while it is going. Joinable runs carry an Attach link that puts you at a real prompt in that run's own working directory, with transcript replay afterwards. While a run is live you can steer it — your message is injected at the next tool boundary — interrupt it for a cooperative stop that still produces a summary, or resume a parked run so it keeps its context instead of starting cold.
Not with task isolation on. Each agent-executed Task gets its own branch, cut from a base branch you choose, and a private working copy, so two Agents working at the same time never overwrite each other. When the Task finishes you get a pull request instead of a direct commit. If the base branch moves on and the Task branch can no longer merge, it flips to a conflict state that names the exact conflicting paths, and Resolve conflicts re-runs the Agent against them. You configure it under Work → Settings → Tasks & Branches.
Quality gates. You declare the commands that decide whether work is really done — build, test, lint, type check, or anything custom — and a red required check hands the Agent the failing check name, exit code and log tail instead of handing the work to you. The policy is per Work: off, warn (report only), or required, where red blocks completion. The fix-it loop is bounded by a gate-attempt budget of one to five, so a stubborn failure stops rather than looping forever, and checks run with a scrubbed environment that never sees platform credentials.
You do, by default. The platform ships with agent merging off, a green gate required, a recorded human approval required, squash as the only permitted method, and main, master, develop and stage protected. You can loosen any of that field by field at the tenant, organization, Work or Agent level — resolution is a deep merge, so setting one field never silently resets the others — and the API can show you the effective policy plus exactly which scope contributed each field.
The Knowledge Base is per Work: a typed, Git-backed store of institutional context — brand voice, legal copy, SEO conventions, glossary, personas, prior research — with a three-pane authoring workbench, locks and Git history. Memory is the layer above it: every Work's Knowledge Base plus your organization-level documents in one searchable, faceted list, alongside uploaded files, what Agents remember from their runs, ingested meetings and a review queue for agent-written material. Memory aggregates the same rows — it adds no second copy of your knowledge.
Drag a file onto the workbench tree and the platform stores the original verbatim, then produces an agent-readable markdown extract: PDF text layers, Word documents, Excel workbooks as one table per sheet, CSV and TSV, PowerPoint slide by slide, Markdown and HTML. Video is normalized to MP4 and audio to MP3 with a transcript. Source URLs take the extractor route instead — including Notion pages, and scanned PDFs where OCR is configured. Anything with no extractor route is still stored and downloadable, and the workbench says so rather than failing quietly.
Yes. Brand, legal, glossary, style, persona and page-matched SEO documents are injected deterministically into every relevant run, under a token budget. Research, freeform and agent-authored documents are retrieved by similarity, and every use is recorded as a citation, so you can audit exactly what context produced a given output. Retrieval is hybrid — a lexical filter and a vector search fused by Reciprocal Rank Fusion — and the workbench AI panel answers with citations too.
Every account gets 50 free credits a day, on cloud and self-hosted alike, and no card is required. The daily grant is added to your balance once a day and does not expire, so an unused day is not lost. And runs on your own model keys cost no credits at all — on any plan, including Free, on either hosting. That is the one path to running at zero credit cost.
A seat is an employee or an agent — the two are interchangeable, because an AI worker here is a member of your team rather than a feature you switch on. The cloud Free plan includes 1 seat; the paid tiers include 10 and charge $5 a month per additional employee or agent on Pro. Enterprise swaps that for two structures: one organization with unlimited employees or agents at no per-seat charge, or unlimited organizations with 10 included in each and $10 a month per additional employee or agent. Self-hosting the Community Edition has no seat count at all.
Pro adds 3,000 credits every month on top of the daily free ones, up to 10 agent sessions at once, and the Slack, pull-request review, Linear, Notion and meeting-transcript integrations. Enterprise adds 25,000 credits a month, unlimited concurrent sessions and merge policy across your whole organization. Run low and you can buy a credit pack from Settings → Billing on any plan and any hosting, wherever payments are enabled: $10 for 1,000 credits, $50 for 5,500, or $200 for 25,000. Every grant and every debit is a line item in a ledger you can filter and export.
The Community Edition is free and open source under AGPLv3, with unlimited employees and agents on your own hardware. Pro Edition and Enterprise Edition are commercial licenses that lift the AGPLv3 obligations and carry the same entitlements as the matching cloud plans — Pro Edition is $49 a month, or $99 once for a lifetime license. Credits stay a separate axis: a self-hosted run that calls Ever-hosted AI spends them exactly as a cloud run does, and a run on your own model keys spends none.
The Slack app is bidirectional: mention the bot in a channel or use its slash command, and the answer comes back in the thread. Point a repository webhook at the platform and Agents review your pull requests — a byte-capped diff plus Knowledge Base context and memory recall, one structured review per pushed revision. Eleven native connectors ship today: Slack, Discord, Linear, Notion, Jira, HubSpot, Pipedrive, Zoom, Google Workspace, Bluesky and Mastodon, each talking to its provider through that provider's own official SDK.
Three front doors, all onto the same API. The MCP server exposes 74 tools — 66 whitelisted API operations plus the Knowledge Base namespace, work registration and a health check — over stdio or streamable HTTP, so any MCP client can drive your Works, Missions and Ideas. The CLI installs with npm install -g ever-works-cli and carries auth, work, plugins and kb command groups. And the REST API is first-class: authenticate with a session token or an API key, up to ten keys per user.
Everything external is a plugin — AI providers, search engines, deployment targets, storage, vector stores, connectors, job runtimes, notification channels — and the repository holds 102 of them across the 19 capability categories that ship with a plugin today, with new ones addable without touching core code. In the other direction, an Inbound Trigger gives you a signed HTTPS endpoint: each verified call creates a Task from your own template, assigns it to the Agent you nominated and starts the run. A deploy finishing, a form submission, a monitor tripping at 3 a.m. — each becomes work that is already moving.
Wherever you decide — which is why self-hosting is a first-class path here rather than a footnote. Run the platform on your own Docker or Kubernetes infrastructure and the database, the repositories and the uploaded originals never leave it; enroll Fleet nodes and the agent runs execute on your machines too. On the hosted platform your Works still deploy to a target you choose — Vercel, your own Kubernetes cluster, or the managed Ever Works cluster — and the Git repositories can sit in your own GitHub organization from the first commit.
An API key is shown once, at creation. Only its short display prefix is kept in the clear; the rest is stored as a SHA-256 hash the API looks up on each request, so the full key cannot be recovered from the platform — lose it and you issue a new one. You can hold up to ten keys per user, each with an optional expiry, and last use is stamped automatically. A magic sign-in link works exactly once and expires after 15 minutes; an expired or already-used link says so and offers a new one instead of failing silently.
Two records, and they agree with each other. The Activity log holds every generation, deployment, import, plugin change, schedule run and sign-in, newest first, expandable to the exact action, its metadata and the raw JSON, with live logs while a generation is running and a CSV export of the whole history. Underneath it, Git is the second audit trail: content, code and Knowledge Base changes are commits in your own repositories, with the diff and the author attached.
The docs go deeper on every feature named above, the roadmap says what is shipped and what is still in progress, and the whole platform is open source — read the code, open an issue, or ask in Discord and get an answer from the people building it.
Describe what you want to build. Ever Works researches it, ships it, and keeps it improving — content and code, owned in your own Git.