gMCP Server Version Security

We’ve talked about some basic security for the server version of gMCP in the main post, but there are some other steps that you really should take if you’re going to be using the platform regularly.

None of this is difficult, but it’s important and some steps should be done regularly.

Log In With An SSH Key Only

You’ve already set up a sudo user and an SSH key. The next step is to stop the server accepting passwords at all, and to stop anyone logging in directly as root. Bots hammer every public server with password guesses constantly and this shuts that door completely.

Log in to your Droplet and create a new settings file:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Add these two lines:

PasswordAuthentication no
PermitRootLogin no

The “00-” at the start of the filename matters. Ubuntu reads these files in alphabetical order and the first setting it finds wins and some Droplets ship with a cloud-init file that quietly switches password logins back on. Naming yours to load first beats it.

Before you restart anything, check that the settings took effect:

sudo sshd -T | grep -E "passwordauthentication|permitrootlogin"

You should see both set to “no”. Then restart SSH:

sudo systemctl restart ssh

Important: Don’t close your current session just yet. Open a second terminal and check you can still log in as your sudo user. If you can’t, you’ve still got the first session open to fix it.

Add A Cloud Firewall

DigitalOcean has a free Cloud Firewall that sits in front of your Droplet, outside the server itself. That makes it a good second layer, since a mistake inside the server can’t switch it off.

In your DigitalOcean dashboard, go to Networking, then Firewalls, and create one with these inbound rules:

• SSH (port 22): Leave it open to anywhere if your IP address changes often or you switch locations or devices. That’s fine here, because we’ve already turned off password and root login, so a stolen or guessed password gets nobody in. Your key is what protects it
• HTTP (port 80)
• HTTPS (port 443)

Leave outbound rules at their defaults, then apply the firewall to your Droplet. Port 80 needs to stay open even though you’ll only ever use HTTPS, because Let’s Encrypt uses it to renew your certificate.

Keep The Server Up To Date

This is the step that needs repeating. Security fixes for the operating system and for Docker itself arrive all the time. A server that’s never updated turns into a liability pretty quickly.

Ubuntu can install security updates automatically. Check it’s switched on:

sudo systemctl status unattended-upgrades

If it isn’t running, install and enable it:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Automatic updates don’t cover everything though, and some (kernel updates especially) only take effect after a reboot. Once a month, log in and run:

sudo apt update && sudo apt upgrade

Then check whether the server is asking for a restart:

ls /var/run/reboot-required

If that file exists, run “sudo reboot”. Everything in the stack is set to restart automatically, so gMCP will come straight back up.

On a Droplet built from the one-click Docker image, Docker is installed through apt, so those same commands keep Docker itself up to date too.

Keep The Containers Up To Date

The operating system is only half the battle. gMCP, LibreChat and Caddy run as Docker images and those need updating separately. To update gMCP, which your Google tokens depend on most, run this from your own computer:

ssh youruser@your-droplet-ip "cd ~/gmcp-server && docker compose pull gmcp && docker compose up -d gmcp"

Your connected services and settings are kept. To update everything in the stack at once, including LibreChat, drop the “gmcp” from both places:

ssh youruser@your-droplet-ip "cd ~/gmcp-server && docker compose pull && docker compose up -d"

I’d do this monthly, alongside the server updates. Updating LibreChat can occasionally change how the interface behaves, so it’s worth having a quick look around afterwards.

Updates leave the old images sitting on the disk. Clear them out now and then with

docker image prune

Look After Your Tokens And Backups

Your Google sign-ins live in a folder called “gmcp-data” inside “gmcp-server” on your Droplet. Anyone holding a copy of that folder can use those sign-ins, so if you take backups or snapshots of the server, treat them as sensitive and don’t store them anywhere you wouldn’t store a password. The same goes for the bearer token the installer printed at the end, so keep it in a password manager rather than a text file on your desktop.

If you want to give someone else access to the chat interface, add them deliberately rather than reopening signup:

ssh youruser@your-droplet-ip "cd ~/gmcp-server && docker compose exec api npm run create-user"

Bear in mind that everyone with a login shares the same gMCP connection, so they’ll see the same Google data you’ve connected. Only add people you’d be happy to give that access to.

If Something Goes Wrong

If you ever think the server has been compromised, or you just want to shut it down for good, cut off the access first.

Go to your Google Account’s security settings, find the third-party apps with access to your account, and remove gMCP. That makes the stored tokens useless immediately, wherever they’ve ended up. Then delete the OAuth client in Google Cloud Console and destroy the Droplet.

Wrapping Up

I know that’s a lot of information, but it’s important to follow to keep your data secure. Again, I take no responsibility for your data. That’s down to you, but it’s all pretty easy to follow. You just have to do it.

That’s how to keep your gMCP server secure. It’s not difficult, but it’s important. Enjoy chatting to your Google data.