Self-Hosted Chatwoot: Open-Source Intercom Alternative

At $99/seat/month, a 10-person support team can cost nearly $12,000 per year on Intercom before additional usage-based charges and optional features. Chatwoot is an open-source alternative that provides many of the core capabilities support teams need, including live chat, email ticketing, conversation workflows, customer conversations, automation, and a shared team inbox, without requiring a traditional per-seat SaaS subscription for a self-hosted deployment.

This guide explains how to deploy Chatwoot on a low-cost DigitalOcean Droplet using Docker Compose, Nginx, and Let's Encrypt SSL. It also compares the economics of self-hosting with a per-seat customer-support platform and explains the infrastructure, security, backup, and maintenance considerations that come with running Chatwoot yourself.

Why Self-Host Chatwoot?

Customer support software can become a significant recurring expense as a company grows its support team. With a per-agent pricing model, adding employees can directly increase the monthly software bill even when the underlying infrastructure requirements have not increased proportionally.

Chatwoot takes a different approach. Because it is open source and can be deployed on your own infrastructure, you can run the application on a virtual private server and control the associated infrastructure costs.

Self-hosting can also provide greater control over application data. Instead of sending every customer conversation to a third-party SaaS platform, your organization can operate the Chatwoot installation on infrastructure that you control.

However, self-hosting is not completely free. You are responsible for the server, operating system, Docker containers, database, Redis, backups, security updates, monitoring, SSL certificates, and recovery procedures. The financial advantage comes from replacing recurring SaaS seat costs with infrastructure and operational costs.

Self-Hosted Chatwoot Pricing and Cost Comparison

The figures above are illustrative and should not be treated as current vendor pricing. SaaS pricing and DigitalOcean infrastructure prices can change over time, and your actual Chatwoot cost depends on the server size, storage, bandwidth, backups, email provider, and traffic generated by your support operation.

The important difference is the pricing model. With a self-hosted installation, adding another support agent does not necessarily require purchasing another infrastructure seat. Your infrastructure cost is primarily determined by resource consumption rather than the number of employees using the application.

What You Need to Run Chatwoot

Chatwoot is more than a single static web application. A production deployment requires several components working together. The application needs a database for persistent data and Redis for caching, background jobs, and other internal operations.

A typical Docker-based deployment includes the Chatwoot application services along with PostgreSQL and Redis. Nginx can sit in front of the application as a reverse proxy and handle incoming HTTP and HTTPS requests.

For a small support team, a modest DigitalOcean Droplet can be a reasonable starting point. As the number of conversations, agents, attachments, background jobs, and concurrent users increases, the server may need additional CPU and memory.

Create a DigitalOcean Droplet

Start by creating a DigitalOcean Droplet in the region closest to your primary users or support team. Choose a current Ubuntu LTS image and a configuration appropriate for your workload.

A $12/month Droplet can work as an entry-level configuration for a small installation, but it should not be considered a guaranteed production configuration for every Chatwoot deployment. The appropriate size depends on the number of conversations, background jobs, email processing, attachments, integrations, and concurrent users.

After creating the Droplet, connect to it using SSH:

ssh root@YOUR_SERVER_IP

Immediately update the operating system:

apt update && apt upgrade -y

For production environments, create a non-root administrative user and use SSH keys rather than relying on password-based authentication.

Install Docker and Docker Compose

Chatwoot's self-hosted deployment can be managed with Docker. Docker packages the application and its dependencies into containers, making the installation more reproducible and easier to maintain.

Install Docker using the official Docker installation instructions for your Ubuntu version. After installation, verify the Docker CLI and Compose plugin:

docker --version
docker compose version

Docker Compose is particularly useful because Chatwoot consists of multiple services. Rather than manually starting and configuring every component, Compose allows the deployment to be described as a collection of related containers.

Download the Chatwoot Deployment

Use the official Chatwoot self-hosted deployment instructions and Docker configuration as the starting point for your installation. Avoid copying random Docker Compose files from untrusted repositories because the configuration may contain outdated images, insecure defaults, or unnecessary services.

Once the deployment files are available on the server, review the environment configuration carefully. Production credentials should be generated specifically for your installation.

Do not use sample passwords, development secrets, or credentials copied from tutorials in a production environment.

Configure the Database

PostgreSQL stores the persistent Chatwoot data, including accounts, users, conversations, messages, configuration, and other application records.

The database should be treated as one of the most important components of the deployment. Losing the database can mean losing customer conversations and support history, so automated backups are essential.

For a small installation, PostgreSQL can run alongside Chatwoot on the same Droplet. As the workload grows, consider separating the database from the application server or using a managed PostgreSQL service.

Database performance should also be monitored. Slow queries, insufficient memory, excessive connections, and disk I/O can affect the responsiveness of the entire support platform.

Configure Redis

Redis is another important part of a Chatwoot deployment. It is used for caching and background processing, allowing work that does not need to happen during the user's HTTP request to be processed asynchronously.

Background processing is particularly important for customer-support platforms because email delivery, notifications, integrations, and other operations can generate asynchronous jobs.

If Redis becomes unavailable or overloaded, background jobs may stop processing correctly even when the main Chatwoot web interface remains accessible. Monitoring Redis health should therefore be part of the production deployment.

Configure Environment Variables

Review the Chatwoot environment configuration before starting the application. Important settings include the application URL, database credentials, Redis configuration, secret keys, mail delivery settings, and storage configuration.

The application URL should use your production domain rather than the server's IP address. For example:

https://support.example.com

Email configuration is particularly important because customer-support workflows often depend on sending and receiving email. Configure a reliable transactional email provider and verify your domain before sending production messages.

Environment files contain sensitive credentials and should never be committed to a public Git repository.

Start Chatwoot with Docker Compose

After configuring the environment, start the Chatwoot services using Docker Compose:

docker compose up -d

Check the containers after startup:

docker compose ps

If a service is not running correctly, inspect its logs:

docker compose logs --tail=100

For a specific service, use its Compose service name to narrow the output. This is much more useful than repeatedly restarting the entire deployment because the logs usually reveal whether the problem is related to environment variables, database connectivity, Redis, networking, or application initialization.

Configure Nginx as a Reverse Proxy

Once Chatwoot is running internally, configure Nginx as the public-facing reverse proxy. Nginx receives requests from users and forwards them to the Chatwoot application running inside the server.

This architecture provides several advantages. Nginx can manage HTTPS termination, HTTP redirects, security headers, request handling, and other web-server functionality while keeping the application services behind the proxy.

A simplified Nginx configuration looks conceptually like this:

server {
    listen 80;
    server_name support.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

The exact upstream address and port should match the Chatwoot deployment you are running. Do not blindly copy configuration values between different Chatwoot versions because deployment requirements can change.

Enable Let's Encrypt SSL

Customer-support applications handle sensitive information, so HTTPS should be enabled before production traffic is allowed.

Let's Encrypt provides trusted TLS certificates that can be used with Nginx. Certbot can automate certificate acquisition and renewal.

After installing and configuring Certbot for your Nginx installation, request a certificate for your support domain. Once HTTPS is enabled, verify that the browser connects without certificate warnings.

Automatic renewal should also be tested. An expired certificate can make a production support application inaccessible to users, so certificate management should not depend on manual intervention.

Configure Email Delivery

Email is one of the most important integrations for a customer-support platform. Your Chatwoot installation may need to send notifications, invitations, conversation messages, and other transactional emails.

Configure a reliable SMTP or transactional email provider and use a verified sending domain. Configure SPF, DKIM, and DMARC records where appropriate to improve email deliverability and protect your domain from spoofing.

Do not use a personal mailbox as the primary production email infrastructure for a growing support platform. Transactional email providers are designed to handle automated application messages and provide better visibility into delivery failures.

Configure File Storage

Customer conversations can contain attachments such as screenshots, documents, images, and other files. Storing these files directly on the Droplet can eventually become a problem because local disk capacity is limited.

For small deployments, local storage may be sufficient. For larger installations, consider using object storage such as an S3-compatible service.

Separating application storage from the server also makes disaster recovery easier. If the Droplet needs to be replaced, application data stored in external object storage does not have to be recovered from the server's local disk.

Secure the DigitalOcean Server

A self-hosted customer-support application should be treated as an internet-facing production service. The server should be protected at both the network and operating-system levels.

Only expose the ports that are actually required. In a typical Nginx-based deployment, public HTTP and HTTPS traffic use ports 80 and 443. SSH should be restricted to trusted addresses whenever practical.

Do not expose PostgreSQL or Redis directly to the public internet. These services should communicate through the internal Docker network or localhost as appropriate.

Keep Ubuntu and Docker updated and remove unnecessary packages and services. Regular security updates reduce the risk of known vulnerabilities affecting the server.

Back Up Chatwoot

Backups are mandatory for any production customer-support system. Conversations and customer records can represent years of business history, so losing them can have serious operational consequences.

At minimum, create automated PostgreSQL backups and store them outside the primary Droplet. A backup stored on the same server does not provide sufficient protection against server failure or accidental deletion.

Keep multiple backup generations and establish a retention policy that matches your business requirements.

Most importantly, test restoration. Schedule periodic recovery tests where you restore a backup into a separate environment and verify that the data is usable.

Monitor Chatwoot Performance

Monitoring helps you determine whether the initial Droplet is still appropriate as the support operation grows.

Track CPU usage, memory usage, disk utilization, network traffic, database performance, Redis health, and Docker container status.

You can inspect Docker resource usage with:

docker stats

If memory usage remains consistently high, investigate which component is responsible before simply increasing the server size. Background jobs, PostgreSQL, Redis, application workers, and file processing can all contribute to resource consumption.

Set alerts for low disk space and sustained resource usage. A server that runs out of disk space can cause database failures, Docker problems, and application downtime.

Scaling Chatwoot

A small Droplet may be sufficient for a small support team, but growth eventually changes the infrastructure requirements.

When traffic increases, first optimize the existing deployment. Review database queries, background jobs, storage, application configuration, and unnecessary workloads.

If the server is consistently reaching its CPU or memory limits, upgrade to a larger Droplet. Vertical scaling is usually simpler than immediately introducing multiple application servers.

For larger installations, the architecture can evolve into separate application, database, and Redis infrastructure. Object storage can also be moved to a dedicated storage service.

The correct architecture depends on the number of agents, active conversations, customer traffic, integrations, email volume, attachment storage, and uptime requirements.

Self-Hosting vs SaaS Support Software

The biggest advantage of self-hosting Chatwoot is control over the infrastructure and pricing model. You can add users without necessarily increasing your infrastructure bill on a per-seat basis.

However, managed SaaS products provide significant convenience. The provider handles infrastructure operations, updates, backups, scaling, and availability. Your team can focus almost entirely on customer support instead of server administration.

Self-hosting therefore makes the most sense when the financial savings, data-control requirements, customization opportunities, or infrastructure preferences justify the additional operational responsibility.

Production Checklist

Before putting a self-hosted Chatwoot installation into production, verify the following:

• Ubuntu is fully updated.
• Docker and Docker Compose are installed correctly.
• Chatwoot containers are running and healthy.
• Production secrets have been generated.
• The production domain is configured.
• Nginx is configured as the reverse proxy.
• HTTPS is enabled with a valid certificate.
• Automatic SSL renewal is working.
• PostgreSQL is not publicly exposed.
• Redis is not publicly exposed.
• SMTP or transactional email delivery is configured.
• SPF and DKIM records are configured where appropriate.
• Automated database backups are enabled.
• Backups are stored outside the primary server.
• Database restoration has been tested.
• Disk usage is monitored.
• CPU and memory usage are monitored.
• Docker logs are reviewed regularly.
• There is a documented recovery procedure.
• A scaling plan exists for future growth.

Final Thoughts

Self-hosting Chatwoot on DigitalOcean can significantly reduce the infrastructure cost of running a customer-support platform, particularly for teams that would otherwise pay a per-agent SaaS subscription.

A modest Droplet combined with Docker Compose, Nginx, HTTPS, PostgreSQL, Redis, and external backups can provide a strong foundation for a small support operation. The key is to recognize that the low server price is only one part of the equation.

Self-hosting transfers responsibility from the SaaS provider to your organization. You need to maintain the operating system, update containers, monitor the application, protect credentials, manage backups, configure email, renew certificates, and plan for recovery.

For organizations comfortable with Linux and Docker, this additional responsibility can be worthwhile. Instead of paying an increasing per-seat subscription as the support team grows, you can invest in infrastructure that you control.

The best approach is to start with a right-sized server, monitor actual resource usage, automate backups, secure the deployment from the beginning, and scale only when real workload data demonstrates the need. With that approach, Chatwoot can become a cost-effective and flexible alternative for teams that want more control over their customer-support infrastructure.

Frequently Asked Questions

Can Chatwoot be self-hosted on a DigitalOcean Droplet?

Yes. Chatwoot provides a self-hosted deployment option that can be run on your own infrastructure. A DigitalOcean Droplet can host the Docker-based application and its supporting services, although the required server size depends on traffic, agents, conversations, background jobs, and storage requirements.

Is self-hosted Chatwoot cheaper than Intercom?

It can be significantly cheaper for teams that would otherwise pay recurring per-seat SaaS fees. With self-hosting, the primary infrastructure costs come from the server, storage, bandwidth, backups, email delivery, and other services rather than directly from the number of support agents. Actual savings depend on your workload and the current prices of the services you compare.

Is Chatwoot suitable for production?

Yes, but production self-hosting requires proper infrastructure management. Use HTTPS, secure credentials, restricted network access, automated backups, monitoring, regular updates, reliable email delivery, and a tested disaster-recovery process before relying on the installation for critical customer-support operations.