Why Trello Keeps Losing Users to Self-Hosted Tools
Trello’s free tier has shrunk considerably over the years – attachment limits, board caps, and the steady migration of useful features behind a paywall have pushed a lot of teams to look elsewhere. The pitch for a self-hosted alternative is straightforward: you own the data, you control the interface, and you pay nothing in recurring subscription fees. Planka, an open-source Kanban board built with React and Elixir, makes that switch surprisingly low-friction for anyone comfortable running a Linux server or a small homelab.
Planka’s interface is visually close to classic Trello – columns, cards, drag-and-drop reordering – so there is minimal relearning for teams already used to Kanban workflows. It supports multiple projects, user accounts, labels, due dates, and card attachments. What it lacks in AI-powered features it makes up for in simplicity and speed. This guide walks through a complete Planka setup using Docker Compose, which is the recommended and most stable deployment method.
What You Need Before Starting
The prerequisites are minimal. You need a server or VPS running a modern Linux distribution – Ubuntu 22.04 or Debian 12 are both solid choices. Docker and Docker Compose must be installed and running. If you plan to expose Planka to the internet rather than keep it local, you also need a domain name pointed at your server’s IP address and a reverse proxy like Nginx or Caddy to handle SSL termination. A firewall that allows traffic on ports 80 and 443 is assumed throughout.
Planka is not resource-hungry. A server with 1 GB of RAM and a single CPU core can run it comfortably for a small team. For anything beyond ten active users, 2 GB of RAM is a sensible floor. Disk space requirements depend almost entirely on file attachments – the base application takes under 500 MB including the PostgreSQL database it spins up alongside itself.
Setting Up Planka With Docker Compose
Start by creating a dedicated directory for the project. Running mkdir -p ~/planka && cd ~/planka keeps things organized. Inside that directory, create a file named docker-compose.yml. Planka requires two services: the application container itself and a PostgreSQL container for data storage. The official Planka repository on GitHub provides a reference Compose file, and the structure below reflects the current stable release.
Paste the following into your docker-compose.yml file, adjusting the environment variables to match your setup:
version: '3'
services:
planka:
image: ghcr.io/plankanban/planka:latest
restart: unless-stopped
ports:
- "3000:1337"
environment:
- BASE_URL=https://yourdomain.com
- DATABASE_URL=postgresql://planka:your_db_password@postgres/planka
- SECRET_KEY=your_long_random_secret_key
- DEFAULT_ADMIN_EMAIL=admin@yourdomain.com
- DEFAULT_ADMIN_PASSWORD=changeme
- DEFAULT_ADMIN_NAME=Admin
- DEFAULT_ADMIN_USERNAME=admin
volumes:
- ./planka-data:/app/private/attachments
depends_on:
- postgres
postgres:
image: postgres:15-alpine
restart: unless-stopped
environment:
- POSTGRES_USER=planka
- POSTGRES_PASSWORD=your_db_password
- POSTGRES_DB=planka
volumes:
- ./postgres-data:/var/lib/postgresql/data
The SECRET_KEY value must be a long, randomly generated string – at least 64 characters. You can generate one with openssl rand -hex 64 directly in your terminal. The BASE_URL must match exactly what users will type into their browser, including the protocol prefix. Getting this wrong is the single most common setup mistake, and it causes session and cookie errors that are frustrating to diagnose after the fact.
Once the file is saved, run docker compose up -d to pull the images and start the containers. On first boot, Planka automatically creates the database schema and the admin account defined in your environment variables. Check that both containers started cleanly with docker compose logs -f. If the application container crashes immediately, the most common causes are a malformed DATABASE_URL or a BASE_URL that includes a trailing slash. Planka is strict about both. After confirming the containers are running, open a browser and navigate to http://your-server-ip:3000 to verify the login screen appears before you configure the reverse proxy.
Configuring Nginx as a Reverse Proxy
Running Planka directly on port 3000 without SSL is acceptable for local-only use, but any internet-facing deployment needs HTTPS. The cleanest approach is an Nginx server block that proxies traffic to the Docker container. Install Nginx with sudo apt install nginx, then create a new config file at /etc/nginx/sites-available/planka. The server block should listen on port 443 with SSL certificates from Let’s Encrypt – obtain those first with sudo certbot –nginx -d yourdomain.com if you have not already.
Inside the server block, the key directives are proxy_pass http://127.0.0.1:3000; along with standard proxy headers: proxy_set_header Host $host;, proxy_set_header X-Real-IP $remote_addr;, and proxy_set_header X-Forwarded-Proto $scheme;. Planka also uses WebSockets for real-time card updates, so add proxy_http_version 1.1; and proxy_set_header Upgrade $http_upgrade; with proxy_set_header Connection “upgrade”; to the location block. Without those WebSocket headers, the board will appear to load but cards will not update live across multiple browser sessions – a subtle bug that only surfaces when two people are working simultaneously.
First Login, User Management, and Backups
After the reverse proxy is active and DNS has propagated, log in at your domain with the admin credentials set in the Compose file. The first thing worth doing is changing the admin password under account settings – the default value in the Compose file is plaintext and visible to anyone with access to that file on the server. From the admin panel, you can invite additional users by email or create accounts directly. Planka does not currently support SSO or LDAP out of the box, which is a real limitation for larger organizations running Active Directory. Third-party integrations and OIDC support are on the project’s development roadmap, but they are not stable in the current release.
Backups deserve attention before you start moving real work into the tool. The two things that must be backed up are the PostgreSQL database and the attachments volume. For the database, a cron job running docker exec planka-postgres-1 pg_dump -U planka planka > /backups/planka-$(date +%F).sql daily is sufficient for most teams. The attachments directory mapped to ./planka-data can be synced to an off-site location with rsync or included in whatever backup strategy already covers your server. Skipping attachment backups is a common oversight – the database alone will restore your board structure and card text, but every uploaded file will be gone.
Planka updates are handled by pulling the latest image and restarting the compose stack. Running docker compose pull && docker compose up -d from the project directory fetches any new release and applies it. Database migrations run automatically on startup. The project follows a relatively conservative release schedule, so updates are infrequent enough that manual pulls are manageable. If you want automated updates, pairing a notification tool like Ntfy with a Watchtower container gives you automatic image updates with an alert pushed to your phone when a new version goes live.
The one ongoing friction point with Planka is its mobile experience. The web app is responsive and usable on phones, but there is no native iOS or Android app in the official project. A few community-built wrappers exist in app stores, but their update cadence does not always track the main project. Teams that live in mobile-first workflows may find that limitation more significant than any feature gap compared to Trello’s paid tiers.
