Taking Mattermost to Production on PaaS: Public IP, TLS, Firewall, Backups and Scaling

A one-click Mattermost install gives you a working chat server on a platform subdomain in about three minutes. Turning that into something a company depends on every working hour is a different job, and this post is the checklist a DevOps engineer follows to do it on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic.

The engineer works for a 60-person software company we will call Pinewood Labs. The company has just installed the Mattermost Chat Service package and wants it hardened before the first team is moved over. The items below are in the order she did them.

1. Give the server a stable public address

Out of the box the environment is reachable through the platform's Shared Load Balancer on a subdomain, which is fine for a trial. For production the engineer attaches a public IPv4 address to the Mattermost node from the topology wizard. The docs recommend this for production because traffic then flows directly to the container rather than through shared infrastructure, and because several features, including custom SSL and WebSockets on non-standard ports, depend on it. A public IP is a paid option billed per hour; for a chat server that runs all month it is a small, fixed line.

Enabling the public IP disables access via the shared balancer, so the engineer does it before publishing the DNS name, not after. She then creates an A record for chat.pinewood.example pointing at the address.

2. Issue a certificate the mobile apps will accept

Mattermost's desktop and mobile apps are stricter about certificates than a browser. A self-signed or platform-subdomain certificate causes the mobile app to refuse the connection outright, so a trusted certificate on the company domain is a requirement, not a polish item. The Let's Encrypt Free SSL add-on installs onto the Mattermost node, issues the certificate for the domain and schedules renewal automatically, starting 30 days before expiry. The engineer verifies it once from a phone on mobile data, not office Wi-Fi, to make sure the chain is complete from the outside.

3. Close every port you do not use

Every container on the platform has a container firewall with inbound rules denied by default except the ones the stack needs and the platform's own management access. The engineer reviews the Mattermost node's rules and leaves exactly two inbound entries: 443 for HTTPS, which also carries Mattermost's WebSocket traffic, and 80, which redirects to 443 and is needed for the Let's Encrypt HTTP challenge. The PostgreSQL node has no public IP and its 5432 is reachable only from the environment's internal network. If the company later wants an admin to connect to PostgreSQL with a desktop client, the platform's Endpoints feature maps the port through the shared balancer on a random public port without exposing the database permanently.

Because Pinewood also runs a staging copy, the engineer puts the production environment in its own environment group with network isolation switched on. Containers in an isolated group cannot be reached over the internal network by environments outside it, which protects production from a staging clone that still carries the production database hostname in its configuration.

4. Back up the two things that matter

A Mattermost server is two data sets: the PostgreSQL database (users, channels, messages, preferences) and the file store (uploads and attachments). The engineer installs the Database Backup/Restore add-on on the PostgreSQL node, points it at a Backup Storage node in the same environment group, and sets a nightly schedule with a two-week retention. For the file store she mounts the uploads directory from a dedicated storage container so the files live on a node whose only job is data and whose disk limit is easy to grow. Restores are tested once on the staging clone, which is the only way to know a backup works.

5. Let the node grow on Monday morning

Chat load is spiky in a very predictable way: everyone connects at nine, files are shared in bursts, and a company-wide announcement produces a thousand simultaneous reads. The engineer does not size for the peak. She sets the Mattermost node to a low reserved cloudlet count and a dynamic limit roughly four times higher, and lets automatic vertical scaling give the container more RAM and CPU as the connected clients arrive, then take it back. Charges are per hour on the greater of RAM used and CPU used, so a quiet Sunday costs a fraction of a busy Monday.

She also adds a load alert: email when the node exceeds 80% of its cloudlet limit for more than 10 minutes. That alert is the signal to raise the limit, long before users notice slow searches. The platform's statistics view shows the same data per minute, so after a month she can see the real curve and set the limit from evidence rather than guesswork.

6. Upgrade without fear

Mattermost releases monthly. Because the server runs in a platform-managed container with its data on persistent volumes, an upgrade is a container redeploy to the new image tag with the data preserved. Before each production upgrade the engineer clones the environment, redeploys the clone first and lets a few engineers use it for a day. If a release breaks a plugin, production is untouched and the clone is deleted. The clone costs only the cloudlets it uses while running, which for a day of light testing is a few cents.

Frequently Asked Questions

Do I need a public IP, or can I use the shared load balancer in production?

The shared load balancer works for small deployments and supports WebSockets on 80 and 443. The platform recommends a public IP for production because it gives you a direct, stable entry point that is unaffected by other tenants and unlocks custom SSL and other features. For a company chat server the hourly cost of an IP is small relative to the benefit.

How do I move Mattermost's uploads to S3-compatible storage instead?

Mattermost supports S3-compatible object storage natively in its file settings. You can point it at any provider, or keep files local on a platform storage container as described here, which is simpler and keeps the data inside the same region as the database.

Can I run two Mattermost nodes for high availability?

Mattermost's built-in cluster mode is an Enterprise feature. On the Team Edition, the platform gives you availability through isolated containers on separate hosts, live migration of a container away from a failing host and fast redeploys, plus nightly backups. For most companies under a thousand users that is sufficient.