Choosing between a hosted and self-hosted personal agent is not a choice between “easy” and “private.” It is a choice about who operates each part of the system, where its data moves, and which failures become your responsibility.
That distinction matters more for a personal agent than for a simple chat app. An agent may hold ongoing Tasks, call a model, search the web, connect to other services, work in a computer environment, and return later with a result. Moving the application onto your own machine changes some of those boundaries. It does not automatically move every dependency with it.
Comma offers both paths: a hosted service operated by Comma and an open-source deployment you can run with Docker Compose. The product is recognisable in either form, but the operating model and some capabilities are not identical. This guide explains the tradeoff without treating self-hosting as a badge or hosted software as a compromise everyone should avoid.
The short answer
Choose hosted Comma when you want to use the agent without becoming its infrastructure operator. Comma runs the service, stores the hosted workspace data, handles updates and backups, and provides a cloud computer for the workspace. The hosted product also includes the meeting-recorder path described by Comma. You accept the service’s account, plan, data-handling, and availability boundaries in exchange for that managed experience.
Choose self-hosted Comma when controlling the application stack, databases, model configuration, and deployment environment is worth the operational work. Your instance runs on a machine you manage, and its application data lives in databases and object storage you operate. You also own upgrades, backups, public-network configuration, capacity, monitoring, and incident recovery. Model calls and optional integrations may still send data to external providers.
Neither choice removes the need to understand permissions and connected services. The useful question is not simply Where is Comma installed? It is Who runs each component, and where does information go when this Task executes?
Compare ownership, not slogans
The official self-hosting guide makes the division concrete:
This is not a feature score. For one person, managing five persistent volumes and a reverse proxy is an unnecessary distraction. For another, putting the application and its records on infrastructure they control is the main reason to use the product. The better option is the one whose responsibilities you can actually sustain.
Follow the data path
“Self-hosted” describes where the Comma stack runs. It does not mean that every byte stays on that machine.
In the default self-hosted stack, Tasks, chats, and files are stored in services you operate. The Compose deployment includes PostgreSQL, Redis, ClickHouse, MinIO, and a configuration volume alongside the Comma server and clients. Comma’s guide states that the stack does not send analytics or traces to Comma. That is a useful boundary, but it is not the end of the data-flow analysis.
When the agent calls a model, the request goes to the model provider configured for that instance. If you add an Exa key for web search and page reading, relevant requests go to Exa. If you make the instance public, login codes need a real mail server. Connected apps and any websites the agent uses remain separate services with their own data handling. A reverse proxy, DNS provider, hosting company, and backup destination may also become part of the operational path you design.
Hosted Comma has a different path. Comma operates the application and stores the hosted workspace data, while model and integration paths depend on the hosted configuration and services you choose. Hosting removes server administration; it does not remove the need to decide what to connect or what information a Task should use.
For either deployment, map one realistic workflow before making a broad privacy claim. If a Task summarises a Drive document with an external model, ask:
Where is the Task and document reference stored?
Which service retrieves the source?
What content is included in the model request?
Which provider receives that request?
Where are the result, logs, and backups retained?
Who can revoke the connection or delete the stored state?
That exercise reveals more than the label on the deployment. Self-hosting can give you direct control over important stores and configuration, but the complete path is a property of the workflow you build.
Bring your own model is a routing decision
Comma’s self-hosted configuration lets you set the model provider endpoint, protocol, model ID, API key, context budget, and output limit. Provider calls use your provider account, so billing and provider terms belong to that relationship rather than to Comma credits.
This flexibility supports several arrangements. You can use a commercial model API under your own account, point to a compatible private endpoint, or configure a model you operate. Those options should not be collapsed into “local AI.” A self-hosted Comma instance that sends prompts to a cloud model still has an external model data path. Running a private model can change that path, but only if the configured endpoint and the surrounding infrastructure are actually under the boundary you intend.
The same care applies to credentials. Operating the stack means protecting model keys, generated secrets, mail credentials, and any tokens used by integrations. Control over configuration is valuable precisely because configuration carries responsibility.
Self-hosting means operating a system
The public repository provides a complete single-node Docker Compose starting point. It builds the web client, admin client, and server, and starts the supporting data services. The first launch can be local: its ports bind to loopback by default, and Mailpit provides a local inbox for login codes.
That local success is not a production-readiness certificate. A public deployment needs HTTPS behind a reverse proxy, separate origins for the web app, admin app, and product API, and a real SMTP service. Public registration is off by default. You need to decide who can reach the instance, how certificates and DNS are managed, how secrets are stored, and how security updates are applied.
Backups are also a system property, not a copy of one database. Comma’s guide says to stop the stack and back up all five named volumes together: config, postgres, objects, clickhouse, and redis. The configuration volume contains the encryption key and authentication secrets. Losing it while retaining other volumes can leave you with data that is not meaningfully recoverable. A backup plan is incomplete until a restore has been tested.
Upgrades add another obligation. You need maintenance windows, enough disk space for builds, a way to detect failed services, and a rollback or recovery plan appropriate to your use. If the agent becomes part of daily work, the machine’s availability, storage health, and network configuration become product concerns that the hosted service would otherwise absorb.
Open source changes what you can inspect and modify; it does not eliminate this operational work. Comma’s original code is licensed under AGPL-3.0-only, and the repository explains the source-availability obligation for modified versions you serve. That is meaningful control, but it is distinct from a security audit, support contract, or guarantee that a particular deployment is correctly configured.
Cloud computers are not the same capability in both paths
The hosted product supplies a cloud computer for a workspace. This gives the agent an environment for work that needs files, tools, or browser-like execution beyond a single model call, without asking the user to provision that environment separately.
As of 26 October 2026, group cloud computers in the public self-hosted stack are off by default and require Cloudflare configuration. The repository does not turn that capability into an automatically available local sandbox merely because the core services are running. If cloud-computer work is central to your Tasks, include its runtime, configuration, cost, isolation, and maintenance in the decision—not just the application server.
This can change the practical answer. Someone who mainly needs persistent Tasks, connected model calls, and control over stored application data may accept the additional setup. Someone who expects a ready-to-use execution computer as part of the agent experience may prefer hosted Comma even if they are capable of running Docker.
Meeting recording has a separate runtime boundary
The same warning applies to meetings. As of 26 October 2026, Comma’s hosted experience includes meeting recording, but the public self-host repository states that meetings and Agent VMM hosts need runtimes the repository does not include.
Self-hosting the core application therefore does not reproduce the full hosted meeting path. You could build or integrate additional infrastructure, subject to the permissions, recording laws, storage design, and transcription providers relevant to your situation. That would be a system you operate, not an included switch in the standard Compose stack.
Treat this as an explicit product boundary. If recording and processing calls is a deciding use case, hosted and self-hosted Comma are not interchangeable today.
A responsibility test before you choose
The most useful self-hosting question is not “Can I run Docker?” It is “Do I want to own this service after the successful first launch?”
Self-hosting is a strong fit when you have a durable machine or server, can protect and back up its state, understand the external providers you configure, and value direct control enough to maintain the deployment. It becomes especially relevant when you need your own network boundary, model endpoint, retention process, or source-level customisation.
Hosted Comma is a strong fit when the outcome matters more than the server, you need the managed cloud computer or meeting path, or you do not want personal-agent availability to depend on your maintenance habits. Choosing hosted does not prevent you from setting careful permissions or limiting what you connect. It simply assigns infrastructure operation to Comma.
Before deciding, answer these questions in writing:
Which data must be stored on infrastructure I operate?
Which model provider will receive Task content, and under which account?
Do my main workflows require a cloud computer or meeting recording?
Can I administer HTTPS, mail delivery, secrets, updates, and access control?
What is my backup set, and have I tested restoring it?
Who notices and fixes an outage while I am away?
Am I choosing self-hosting for a concrete boundary, or only because the word sounds safer?
If the answers point in different directions, start with the deployment that supports your most important workflow. You can learn more from one bounded Task and its real data path than from an abstract feature comparison.
Questions about hosted and self-hosted personal agents
Is self-hosted Comma automatically more private?
No. It places the application stack and its databases under your control, and the standard stack does not send analytics or traces to Comma. Model providers, search, mail, connected apps, network services, and backups can still receive or store data. Privacy depends on the complete configuration and workflow.
Does self-hosted Comma require a Comma account or subscription?
The public Docker Compose stack does not require a Comma account, Stripe, or Comma credits. You provide the machine and configure a model provider account or private model. Those choices can have their own infrastructure and usage costs.
Can I use my own model provider?
Yes. The self-hosted stack exposes configuration for a provider endpoint, protocol, model, and credential. A provider you run yourself is possible if it supports the required interface, but self-hosting Comma does not by itself make a third-party model local.
Does the self-hosted version include a cloud computer?
Not as a ready-to-use default. Comma’s official guide says group cloud computers need Cloudflare configuration. Plan for that separate setup and its operating boundary if your workflows depend on computer execution.
Does the self-hosted version include the meeting recorder?
No. The public repository says meeting runtimes are not included. The hosted service and the standard self-hosted stack therefore differ for this use case.
What must I back up?
Back up the five named volumes—configuration, PostgreSQL, objects, ClickHouse, and Redis—as one set while the stack is stopped. Preserve the configuration volume because it holds encryption and authentication secrets. Follow the current self-hosting guide before an upgrade or restore.
Is open source the same as secure?
No. Source availability makes inspection, modification, and independent operation possible. Security still depends on the code, its dependencies, your configuration, network exposure, credentials, update practices, and operational response.
Choose the boundary you can maintain
A hosted personal agent asks you to trust and evaluate a service operator. A self-hosted personal agent asks you to become one. Comma supports both because control and convenience are not universal preferences, and because the right boundary depends on the work you plan to delegate.
If you want the managed experience, start with hosted Comma. If you want to operate the stack, read the complete self-hosting guide, inspect the official repository, and plan the model, network, backup, cloud-computer, and meeting boundaries before you put important Tasks on it.
