Front vs Chatwoot: when each fits and what the decision turns on
Chatwoot fits teams that want one self-hosted inbox for website live chat, email, WhatsApp, Facebook, Instagram, Telegram and SMS, with conversation history on servers they control. Front fits teams that want a managed service and prefer the vendor to handle hosting, patching and uptime. The decision turns on four questions. First, where customer data must live: if a regulator or internal policy requires conversations and attachments to stay in your own cloud account or data center, Chatwoot's self-hosted model answers that directly. Second, which channels carry your volume: confirm each channel you depend on is supported before planning the migration, because a channel that is hard to replace is the costliest gap to close later. Third, who will run the platform. Fourth, whether per-seat pricing or self-hosted server and staff cost is easier to justify to finance.
Compare cost by component, not by headline price. Chatwoot's Community Edition is free to self-host. The Premium Support plan, at $19 per agent per month according to Chatwoot's self-hosted plans page, adds roles and permissions, custom branding and Captain AI, and the Enterprise Edition, at $99 per agent per month, adds SAML single sign-on and SLA policies. Front's per-seat tiers are set by Front, so request a written quote for your seat count and your required features. Then build the Chatwoot side from the per-agent fees plus servers, PostgreSQL, Redis, backups, email deliverability and the hours needed to operate them. Ask Front which features behind its seat tiers your team uses today, such as single sign-on or permissions, so you compare like with like.
Operating capacity is the constraint teams most often underestimate. Chatwoot requires Ruby 3.2 or later, recommends Node.js 20.x and Redis 7.0 or higher, and supports only PostgreSQL as its database. Its requirements page lists Ubuntu 20.04 as the only officially supported Linux distribution, so check that against your patching policy before choosing an operating system. Sizing guidance starts at 4 CPU cores and 4 GB of RAM for up to 10,000 conversations a day, and 8 cores and 8 GB for up to 20,000, plus at least 1 GB of swap. Measure your own daily volume before you commit to a size. If nobody on your team can own that stack on call, a managed Front plan may be the better operating choice. Run a pilot on one inbox to test channel connections and load before any cutover.
Which option fits which situation
This table matches common team situations to the option that usually fits better, with the reason tied to Chatwoot's channels, reports and deployment paths. Read each row against your own channel mix, data location rules and platform skills, since the right answer depends on those factors more than on feature counts.
| Situation | Better fit | Reason |
|---|---|---|
| Multi-channel support team with website chat, email and social messaging | Chatwoot | Chatwoot places website live chat, email, Facebook, Instagram, Twitter, WhatsApp, Telegram, Line and SMS in one inbox, so agents work one queue across these channels. |
| Team that must keep customer conversations in its own cloud or data center | Chatwoot | Chatwoot is MIT-licensed and can run on a Linux VM, Docker or Kubernetes in your own accounts, so conversation data stays under your control. |
| Team with no platform engineers | Front (or a managed Chatwoot arrangement) | Self-hosting Chatwoot requires PostgreSQL, Redis, Ruby and Node.js upkeep, plus backups and upgrades. Confirm whether you can staff that work or need a partner to run it. |
| Team that depends on Front's omnichannel analytics | Front, until you confirm Chatwoot's reports meet your needs | Chatwoot's README lists conversation, agent, inbox, team and CSAT reports. Compare them with the dashboards your managers use before deciding. |
| Team already running Kubernetes | Chatwoot | Chatwoot documents a Helm chart for Kubernetes aimed at larger high-availability deployments, which fits an existing cluster and its operating practices. |
| Team with a small number of agents and mostly email traffic | Depends on channel needs, possibly FreeScout | If you do not need social or messaging channels, a shared-inbox tool may cover the work with less infrastructure. Compare with the Front vs FreeScout page. |
| Team that needs SSO with SAML and SLA policies | Chatwoot Enterprise Edition, or confirm the requirement with Chatwoot | Chatwoot's self-hosted plans page lists SSO with SAML and SLA policies in the Enterprise Edition, which is a paid tier. Ask Chatwoot to confirm current terms. |
| Team that wants AI-assisted replies without building its own model stack | Chatwoot paid tier, after testing Captain in your environment | Chatwoot's README describes Captain for automating responses to common queries, and the plans page lists it in Premium Support. Test its answers on your own content before relying on it. |
Where customer conversations live and who operates them
Front is a vendor-hosted cloud service. Your team signs up, configures inboxes and channels, and Front's operations staff run the application, databases and infrastructure. Customer conversations, attachments and contact records are stored in the vendor's environment, so data location is governed by Front's hosting regions, contract terms and subprocessor list rather than by your own change controls.
- Data location: Ask Front where each data category is stored, which regions are used for backups, and which subprocessors touch message content.
- Operational control: Upgrades, patching, outage response and backup restoration happen on the vendor's schedule and under its terms.
- Identity: Sign-in, multi-factor policy and access reviews are managed through Front's administration settings and any identity provider it supports for your plan.
- Evidence: Request the vendor's current third-party assurance reports under a non-disclosure agreement and review them against your own control requirements.
- Exit data: Confirm what export formats and volumes are available if you leave, and whether attachments are included.
Before renewal, confirm in writing which of these items your plan covers, because they determine how much of the control evidence you can inherit from the vendor.
The Chatwoot Community Edition can be installed on a single Linux virtual machine with the installation script that Chatwoot documents. Your team owns the server, the PostgreSQL database, Redis and the mail configuration, so conversations and attachments remain in the environment you choose. Chatwoot documents Ubuntu 20.04 as the only officially supported Linux distribution, which is a constraint you should weigh against your own patching standards.
- Requirements: Plan for Ruby 3.2 or later, Node.js 20.x, PostgreSQL as the only supported database and Redis 7.0 or higher.
- Sizing: Chatwoot's requirements page recommends at least 4 CPU cores and 4 GB of RAM for up to 10,000 conversations a day, and 8 cores and 8 GB for up to 20,000, plus at least 1 GB of swap.
- Operations: Your team handles OS patching, database backups, TLS certificates and restore tests.
- Identity: Community Edition does not include SSO with SAML, so agent sign-in relies on Chatwoot's local accounts unless you add an edge access layer.
- Licensing: Code outside the enterprise/ directory is MIT Expat licensed, and the enterprise/ directory uses its own license.
Confirm with your security team whether local agent accounts and a single VM meet your authentication and availability requirements before you commit to this model.
Chatwoot also documents Docker deployment and Kubernetes deployment with a Helm chart, which the documentation positions for larger high-availability installations. The container model keeps the same data ownership as a VM but moves process isolation, scaling and rollout into your platform team's tooling. The operational burden moves from the operating system to the cluster, its storage classes, secrets handling and network policies.
- Data location: Choose the cluster's region and storage encryption, and confirm where PostgreSQL and Redis volumes and backups are written.
- Secrets: Store database credentials, the secret key base and mail credentials in your secrets manager, not in Helm values files kept in source control.
- High availability: Decide how the web and worker processes scale, and how Sidekiq workloads behave during node failure.
- Access: Restrict cluster administration to named roles and log changes to deployments and secrets.
- Evidence: Your change records, image provenance and cluster configuration become part of the control evidence auditors will ask for.
If your platform team has no Kubernetes operating experience, ask for the staffing model and the on-call coverage you will need before choosing this path.
Chatwoot publishes self-hosting guides for AWS, Azure, DigitalOcean, Google Cloud and Heroku. These guides change the physical host, not the ownership model: your organization still holds the cloud account, the database and the conversation data. The provider you choose determines the regions, managed database options and shared responsibility split that your auditors will review.
- Account boundary: Run Chatwoot in a dedicated account or subscription with its own identity, logging and billing controls.
- Managed services: A managed PostgreSQL or Redis service can reduce patching work, but you must confirm its encryption, backup retention and access logging settings.
- Regions and residency: Pick regions that match your customers' data residency commitments, including backup and log locations.
- Shared responsibility: Document which controls the cloud provider inherits and which remain with your team.
- Identity: Connect cloud administration to your identity provider with multi-factor authentication and least privilege roles.
Before you choose a provider, ask your compliance lead which provider reports and regional commitments your assessment will accept.
What running Chatwoot requires from your infrastructure
Running Chatwoot means owning a Ruby on Rails and Vue.js application stack, and the decision that matters most is that PostgreSQL is the only supported database. Chatwoot requires Ruby 3.2 or later and recommends Node.js 20.x, and it recommends Redis 7.0 or higher for its background and caching layer. Your platform team should map each of these to a version your patching process already tracks, because the application's upgrade path will depend on them. Plan for PostgreSQL backups and point-in-time recovery from day one, since conversation history, contacts and attachment metadata will live there.
Sizing follows conversation volume more than seat count. Chatwoot's requirements page recommends at least 4 CPU cores and 4 GB of RAM for up to 10,000 conversations a day, and 8 cores and 8 GB for up to 20,000, plus at least 1 GB of swap. It also notes that Sidekiq, the background job processor, can use more than 1 GB of memory on a very active server. Ask your team to measure your peak daily conversation count across email, web chat and social channels, then size the Sidekiq worker and Redis memory separately from the web tier, because a busy email backlog can exhaust memory before CPU becomes the constraint.
Operating system support is the check to run first. Chatwoot lists Ubuntu 20.04 as the only officially supported Linux distribution, and that version is past its standard support window, so confirm the current supported operating systems with Chatwoot before you choose a base image, and record the answer in your architecture decision. If your standard is a different distribution, decide whether to run Chatwoot on a supported image, in Docker, or on a Kubernetes cluster with the Helm chart, and check the self-hosted documentation for the deployment path Chatwoot currently supports for your choice.
What drives the cost of each option
Front bills per seat, while Chatwoot's Community Edition has no license fee and its paid self-hosted tiers are priced per agent. The real comparison is the license line plus servers, database and Redis hosting, email setup and the staff time to run the platform.
Front per-seat plans and seat caps
Front is a recurring subscription priced per seat across its Starter, Professional and Enterprise plans, so cost rises with every person who answers customers. Ask the vendor for the exact seat count, which features each tier gates (such as API capacity and analytics), and what overage or add-on charges apply at your volume. Model the total for your full team, including occasional users like managers and billing staff who may still need a seat.
Chatwoot Community at no license fee
The Community Edition is free under the MIT Expat license, so the software itself carries no recurring license cost. The one-time work is the initial installation, channel setup (website widget, email, WhatsApp, Facebook, Instagram, Telegram and SMS) and any custom integrations you need. Confirm with your team which Community features cover your workflows, because capabilities such as SSO and SLA policies sit in paid tiers.
Premium Support at $19 per agent
Chatwoot's self-hosted plans page lists Premium Support at $19 per agent per month, adding Captain AI, voice calls, custom branding, agent capacity, roles and permissions, and priority support. This fee scales with agent count, so it is a recurring line item that compares directly to your Front seat count. Confirm which add-ons you need, whether Captain AI usage is metered, and how billing handles agents who are only occasionally active.
Enterprise Edition at $99 per agent
The Enterprise Edition, listed at $99 per agent per month on Chatwoot's self-hosted plans page, adds SSO with SAML and SLA policies. Organizations that need SAML sign-on or contractual response targets should price this tier separately from Premium Support, since the two are not interchangeable. Ask whether the rate changes with volume and whether SLA terms are part of the contract or a documented feature.
Servers, database and Redis hosting
Infrastructure is recurring and paid to your cloud provider or data center. Chatwoot's requirements page recommends at least 4 CPU cores and 4 GB of RAM for up to 10,000 conversations a day, and 8 cores and 8 GB for up to 20,000, plus at least 1 GB of swap. You also need PostgreSQL and Redis 7.0 or higher, which may be managed or self-run. Ask your infrastructure team to size for peak conversation volume, not the average, and to price backups and high availability.
Operations, upgrades and staff time
Operations is the largest cost that is easy to miss. Someone must patch the operating system, Ruby, Node.js and PostgreSQL, apply Chatwoot releases, monitor Sidekiq memory use, maintain email deliverability and test backups. Front's operating cost is mostly vendor-managed, so this line is your internal or partner labor. Ask any implementation partner for a fixed-scope quote that names upgrade cadence, backup testing, monitoring and on-call coverage as separate deliverables.
What a move from Front to Chatwoot involves
The sequence turns Front's shared inboxes and channels into a Chatwoot instance on your own infrastructure, with channels cut over one at a time so customers see no gap in service. Each step closes with a check you can verify before the next one starts.
Inventory channels, inboxes and users
Your team lists every Front shared inbox, email address, chat widget, social account and messaging number in use, along with who answers each one, which rules and saved replies they rely on, and which Front integrations feed them. Owners of each channel confirm the list. The output is a written inventory that maps each Front inbox to a planned Chatwoot inbox and team, with the owner named for each. You know this step is done when every active channel has an owner and nothing is left as an unknown.
Confirm which channels Chatwoot must connect
Using the inventory, your team decides which channels move to Chatwoot in the first wave and which stay on Front or retire. Chatwoot's README lists website chat, email, Facebook, Instagram, Twitter, WhatsApp, Telegram, Line and SMS, but each connection depends on account permissions, business verification and provider terms, so confirm every channel against the provider's current requirements. The output is a channel-by-channel decision record. You know this step is done when each channel has a named go or no-go decision and any gap is logged as an open risk.
Provision PostgreSQL, Redis and the application
Your infrastructure or DeployOpen engineers provision PostgreSQL, Redis 7.0 or higher and the Chatwoot application on your own servers or cloud accounts, using the requirements Chatwoot publishes. Chatwoot supports only PostgreSQL, recommends Node.js 20.x, requires Ruby 3.2 or later and lists Ubuntu 20.04 as the only officially supported Linux distribution. Size the host against the published guidance of at least 4 CPU cores and 4 GB of RAM for up to 10,000 conversations a day, and confirm swap. The output is a running instance with backups and monitoring configured. You know this step is done when a test conversation flows end to end on the staging instance.
Configure email routing and deliverability
Your team points inbound mail for each shared address to Chatwoot, sets outbound sending through your mail provider, and configures SPF, DKIM and DMARC records for the sending domains. Front's current sending setup must be kept in place until Chatwoot's outbound path is verified, or customer replies may fail. The output is a documented mail flow for each address with test messages sent and received from outside your network. You know this step is done when inbound and outbound tests pass for every shared address and the DNS changes are recorded.
Rebuild teams, automations and canned responses
Agents, teams, roles, labels, business hours, auto-assignment rules and automation rules are recreated in Chatwoot from the inventory, along with canned responses and help center articles that your team chooses to keep. Chatwoot's README lists these features, but the exact configuration must be rebuilt by hand because no supplied fact confirms an automated export from Front. Confirm which Front rules have a direct Chatwoot equivalent and which need a workaround. The output is a configuration checklist signed off by each team lead. You know this step is done when a test conversation routes to the right team and agents see the expected canned responses.
Export and map Front conversation history
Before any cutover, ask Front for the export formats it provides for your plan and test how the data maps to Chatwoot. No Front-to-Chatwoot migrator is among the supplied facts, so confirm with your Front account team and with Chatwoot how history will be imported, whether by API script, as archived files or not at all. Confirm what is lost, such as attachments, internal notes, assignment history and metadata. The output is a written decision on what history moves, where the rest is archived and who approves that trade-off. You know this step is done when a sample import has been reviewed by the business owners and the loss list is accepted.
Run parallel operation and train agents
Chatwoot and Front run side by side for a period your team sets, with a small pilot group working in Chatwoot on one channel while the rest of the team stays on Front. Track missed messages, misrouted conversations, email delivery failures and agent questions in a shared log. Agents complete hands-on training on the Chatwoot inbox, notes and reports. The output is a pilot log and a list of fixes applied to routing and templates. You know this step is done when the pilot group handles a full working day without fallback to Front on the pilot channel.
Cut over channels one at a time
Your team moves each channel to Chatwoot in the order set in step two, starting with the lowest-risk inbox. For each channel, DNS or provider webhooks are switched, Front forwarding is disabled, and Chatwoot is confirmed as the only receiver. Front access is kept read-only for reference until the history decision in the earlier export step is fully carried out. The output is a cutover record per channel with the time and owner of each switch. You know this step is done when every channel receives and sends through Chatwoot, and no inbound message has arrived in Front for a set period you have confirmed in writing.
Questions buyers ask before switching from Front
What does it cost to move from Front to self-hosted Chatwoot?
The cost has three parts: the software licence, the infrastructure you run, and the one-time migration and setup work. Chatwoot's Community Edition is listed at $0 and free forever, so the software line is zero on that tier. Premium Support is listed at $19 per agent per month and Enterprise Edition at $99 per agent per month, according to Chatwoot's self-hosted plans page. Your servers, PostgreSQL, Redis, email sending and staff time recur. Front's per-seat plans also recur, so compare your current seat count against the Chatwoot tier you need. Ask Front for your current invoice and seat terms, and ask Chatwoot to confirm which features each paid tier includes before you model the figures.
How long does a Front to Chatwoot migration take?
The timeline depends on how many channels you connect, how much history you move, and how many agents need training. Chatwoot is built to run one inbox across website chat, email, WhatsApp, Facebook, Instagram, Telegram, Line, Twitter and SMS, so each channel needs its own provider setup and testing. Email routing and deliverability usually take the longest to verify because DNS and mail settings must match your domain. Front does not offer a Chatwoot migrator in the facts supplied for this page, so historical conversations may need a custom export and import. Ask your implementation partner for a written scope with a timeline before work starts.
Can our team migrate from Front without outside help?
A team with Linux, PostgreSQL, Redis and DNS skills can install Chatwoot, but the work is more than installation. Someone must size the servers, configure each channel, set up email routing, build automations and roles, and plan a cutover that does not drop customer messages. Chatwoot documents a Linux VM install script, Docker, and a Kubernetes Helm chart for larger high-availability deployments, so the deployment path depends on your existing platform. Confirm internally who owns on-call support for the server. DeployOpen plans, implements, customizes, integrates, hardens, backs up and documents self-hosted platforms in your own environment, under a fixed scope agreed in writing.
What must our team provide for a self-hosted Chatwoot deployment?
You must provide the infrastructure, the channel accounts, and admin time. Chatwoot's requirements page recommends at least 4 CPU cores and 4 GB of RAM for up to 10,000 conversations a day, and 8 cores and 8 GB for up to 20,000, plus at least 1 GB of swap. It notes Sidekiq can use more than 1 GB of memory on a very active server. You also need Ruby 3.2 or later, Node.js 20.x, PostgreSQL as the only supported database, and Redis 7.0 or higher. Ubuntu 20.04 is the only officially supported Linux distribution. Prepare admin access to Facebook, Instagram, WhatsApp, Telegram and SMS provider accounts, plus DNS control for your mail domain.
Does Chatwoot cover the reporting we use in Front?
Chatwoot covers conversation, agent, inbox, team and CSAT reports, according to its README. Those reports cover the core customer operations questions: volume, response activity, team output and satisfaction. Front's analytics and any custom dashboards you rely on may not map one to one, so list each report your managers use today and check it against Chatwoot's reports before you commit. Also confirm whether the data needed for those reports can be exported in the format your finance or BI tools expect. Ask Chatwoot to confirm the current report set for the version you plan to run.
What does Chatwoot's Community Edition leave out?
The Community Edition is free, but the paid tiers add capabilities that some teams need. According to Chatwoot's self-hosted plans page, Premium Support adds Captain AI, voice calls, custom branding, agent capacity, roles and permissions, and priority support. Enterprise Edition adds SSO with SAML and SLA policies. If you need single sign-on, defined service levels or granular roles, price those features into the comparison. Confirm with Chatwoot which edition includes each feature, and ask your implementation partner which features your workflows depend on.
Which Front licence terms should we check before we cancel?
Check your contract for the notice period, seat reduction rules, data export rights and any paid API capacity you use. Front is sold per seat across Starter, Professional and Enterprise plans, so the terms that matter are seat counts and renewal dates. Export your conversations, contacts, tags and attachments before the subscription ends, and confirm the format and any limits on export with Front in writing. Also keep records of shared inbox rules and saved replies so you can rebuild them in Chatwoot. Ask Front to confirm exactly what data remains available after cancellation.
Who keeps Chatwoot running after go-live?
Your team or a support retainer must cover upgrades, backups, patching and monitoring after go-live. Chatwoot publishes new releases regularly, including v4.18.0 on September 18, 2026, so plan for a repeatable upgrade routine and a tested restore procedure. Assign an owner for the PostgreSQL database, Redis, mail delivery and the Sidekiq workers. Ongoing support, upgrades and continuous testing are available from DeployOpen as retainers, and scope for those is agreed in writing.
How DeployOpen helps evaluate and move to Chatwoot
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Front vs Chatwoot, the work starts with a written scope that matches your channels, team structure and data needs to what Chatwoot can run in your environment.
How we scope
- Inventory every Front channel in use, including shared email addresses, website chat, WhatsApp, social inboxes and SMS
- Map Front rules, assignments, saved replies and reports to Chatwoot automation, teams and reporting features
- Agree deployment target, PostgreSQL and Redis hosting, and email deliverability requirements in a written scope before work starts
How we build
- Install Chatwoot in your environment using the documented VM, Docker or Kubernetes path that fits your availability needs
- Configure each channel integration and test inbound and outbound messages across email, chat and social channels
- Test automation rules, business hours, auto-assignment and reports against a representative set of conversations before cutover
How we hand over
- Deliver architecture, runbooks, channel configuration records and an agent onboarding guide written for your team
- Document the Front export, historical conversation import approach and the cutover sequence agreed with your team
- Run a handover session covering backups, upgrades, edition choices and the features that differ from Front
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Plan upgrades against Chatwoot release notes and test them in a staging copy before production
- Confirm with your team which support tier, licensing edition and recurring costs apply before the retainer is signed
