Set Up Grist as a Self-Hosted Airtable Alternative

Why Self-Hosting Your Database Tool Actually Makes Sense

Airtable is genuinely good software. It is polished, fast, and easy to teach to a non-technical team. But it is also a subscription product that stores your data on someone else’s servers, prices aggressively as your team grows, and can change its feature tiers at any time. For teams managing sensitive records, internal tooling, or just trying to cut SaaS costs, those are real problems – not hypothetical ones.

Grist is the self-hosted answer to that situation.

It combines the familiar spreadsheet grid that non-technical users can navigate on day one with relational database logic underneath – linked records, formula columns, and multiple views of the same data. The open-source version gives you full control: your server, your storage, your access rules. This guide walks through setting it up with Docker, connecting it to a domain, and configuring it for a real team environment.

What You Need Before You Start

The minimum viable setup requires a Linux server with at least 1GB of RAM, Docker and Docker Compose installed, and a domain name with DNS you can control. A small VPS from any major provider works fine. Grist is not resource-hungry at moderate scale – a two-core, 2GB RAM instance handles small teams without strain. If you are already running other self-hosted tools on the same machine, confirm you have ports 80 and 443 free, or plan to route traffic through a reverse proxy you already manage.

You will also need an SMTP server or relay for email-based login. Grist supports email-link authentication out of the box, which means users click a magic link rather than entering a password. This requires outbound email to work correctly. If you do not have a transactional email provider set up, services like Brevo or Mailgun offer free tiers that cover low-volume internal tools without issue. Have your SMTP host, port, username, and password ready before you start the container configuration.

Optionally, configure an OAuth provider – Google or GitHub – if you want single sign-on for your team. This is not required to get Grist running, but it simplifies access management significantly if your team already authenticates through one of those services. The environment variables for OAuth are straightforward and documented clearly in Grist’s official repository.

Installing Grist With Docker Compose

Create a working directory, then create your docker-compose.yml file inside it. The core service definition is minimal. You pull the official gristlabs/grist image, map port 8484 on the container to whatever local port you want to expose, and mount a local volume for persistent data storage. Without the volume mount, all documents vanish when the container restarts – so do not skip that line.

The environment variables are where the real configuration lives. Set APP_HOME_URL to your full domain including the protocol, for example https://grist.yourdomain.com. Set GRIST_SINGLE_ORG to a short identifier for your team – this locks the instance to one organization rather than running in multi-tenant mode, which is almost always what you want for a private deployment. Add your SMTP variables: GRIST_SMTP_HOST, GRIST_SMTP_PORT, GRIST_SMTP_USER, GRIST_SMTP_PASSWORD, and GRIST_SMTP_FROM. Set GRIST_SANDBOX_FLAVOR to gvisor if your host kernel supports it, which isolates formula execution – a meaningful security improvement if you are giving access to people outside your immediate team. Run docker compose up -d and the container pulls and starts in under a minute.

At this point, Grist is running on your server but not yet accessible from the internet with HTTPS. Use Nginx or Caddy as a reverse proxy to handle SSL termination. Caddy is the faster path: a three-line Caddyfile pointing your domain at localhost:8484 with reverse_proxy directive, and Caddy handles certificate issuance via Let’s Encrypt automatically. With Nginx, you will write a standard proxy pass config and run Certbot separately. Either way, once the reverse proxy is in place and your DNS A record points to the server, the Grist login screen loads at your domain over HTTPS.

First Login, Documents, and Access Control

The first account to log in becomes the owner of the Grist instance. Use your primary email address for this – the one you want to use for administrative access. Grist sends a magic link to that address, you click it, and you are in. From the home screen, you can immediately create a new document, which opens the spreadsheet editor. The interface is close enough to Airtable that most users orient within a few minutes: tables on the left, rows and columns in the center grid, view options along the top.

Where Grist earns its value over a plain spreadsheet is in reference columns and linked sections. A reference column in one table can point to rows in another table, and a linked section displays filtered related records based on whatever row is selected in the primary table. This is how you build a project tracker where selecting a client filters their associated tasks, or an inventory system where selecting a product shows its transaction history. The setup for this is visual – no SQL required – but the data model underneath is genuinely relational. For teams already doing this kind of work in Airtable, the migration path is short because the mental model matches.

Access control works at the document level and, with Grist’s granular permissions system, at the row and column level too. You can share a document with a team member by email and assign them a viewer, editor, or owner role. The more advanced option is access rules – a per-table permission layer where you write simple expressions to restrict which rows a given user can see or modify. A sales team seeing only their own leads, a manager seeing all of them – this is configurable without any external tooling, directly inside the document settings panel. For organizations handling data with any sensitivity, this is where Grist genuinely outperforms most spreadsheet-adjacent tools.

Keeping It Running

Self-hosting means backup is your responsibility. Grist stores documents as SQLite files inside the data volume you mounted. A daily backup of that directory to an offsite location – an S3-compatible bucket, or an encrypted destination via a tool like Duplicati – is the minimum sensible policy. Updates are equally straightforward: pull the new image tag, stop the container, start it again. Grist applies any necessary schema migrations automatically on startup, and because documents are SQLite files rather than a separate database server, there is no migration script to manage manually. A team running Grist on a small VPS with weekly updates and daily backups has a setup that is genuinely lower maintenance than most self-hosted stacks.

The question most teams hit six months in is not whether Grist works – it does – but whether their power users will want Python formula support, the API for connecting Grist to other internal tools, or webhooks for triggering external actions on row changes. All of those exist in the self-hosted version without any premium gate. The Airtable equivalent of that feature set sits behind a plan that costs multiples of what a VPS runs per month.