4ga Boards: a self-hosted kanban board with Trello import and an MIT licence
Straightforward realtime kanban boards management for intuitive task tracking. 4ga Boards features an elegant dark mode, collapsible todo lists, and multitasking tools to supercharge your team's productivity.
At a glance
- What is it?
- 4ga Boards is a JavaScript kanban application you run yourself with Docker Compose and PostgreSQL. The README is clear about deployment and vague about everything after it, so the useful question is which parts are documented and which parts you will be reading source code to answer.
- Who is it for?
- Adopt 4ga Boards if you want a self-hosted kanban board with a documented Docker Compose path, a Trello import step inside the board creation flow, and an MIT licence that lets you modify the code. Do not adopt it if you need GitHub issue sync, a published HTTP API reference, or an upgrade procedure that is documented rather than inferred from the repository.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap 4ga Boards fills, and the one it leaves open
The case for 4ga Boards is narrow and concrete. Trello works, but the board lives on someone else's server. Planka and Focalboard also self-host, so the differentiator is not self-hosting by itself. It is the combination of a Docker Compose deployment the README walks through step by step, a Trello import that sits inside the normal board creation flow, and an MIT licence with no separate enterprise edition mentioned in the material. The README also lists a paid hosted option at 4gaboards.com/pricing, so the project is not purely a volunteer effort, but the repository text does not describe what the paid tier adds.
The audience is a small team that already runs PostgreSQL or is willing to, has a server and a domain, and wants task tracking without per-seat billing. The README's default credentials (user demo, password demo) and its default URL of http://localhost:3000 make the intended first run obvious: stand it up locally, look at it, then move it behind a proxy.
What the README does not give you is a written API. If your plan is to drive boards from scripts, CI jobs or a chat bot, the material here offers no endpoint list, no authentication scheme for programmatic access, and no webhook description. The GitHub two-way sync is listed as coming soon, which means the integration story is currently manual: import once from Trello, then work inside the app.
React on the front, Sails.js in the middle, PostgreSQL underneath
The tech stack section names the pieces: React, Redux, Redux-Saga, Redux-ORM, react-beautiful-dnd and floating-ui on the client; Sails.js and Knex.js on the server; PostgreSQL as the database. That is enough to reason about the shape of the system even without reading the source.
Sails.js is a server framework that ships its own socket layer, and the feature list promises realtime updates without a page reload plus "Multitasking Capabilities" where one user can edit or review cards while another filters and rearranges the board. Those two claims point at the same mechanism: board state changes are pushed over a persistent connection rather than polled, and the client keeps local description edits alive while the surrounding board re-renders. Redux-ORM on the client suggests the browser holds a normalised copy of cards, lists and boards, which is how a drag operation can feel immediate while the write travels to the server.
Knex.js is a query builder rather than a full ORM, so schema changes are likely expressed as migrations in the repository rather than generated from model definitions. The development instructions support that reading: pnpm server:db:init initialises the database, which implies a migration or seed step you run once before pnpm dev. The multi-level hierarchy named in the feature list (projects, boards, lists, cards, tasks) is therefore five tables or more, and any schema upgrade between versions is something you want to test on a copy before touching production.
One caveat on the stack: react-beautiful-dnd is the drag-and-drop library, and the README does not discuss touch behaviour or accessibility for keyboard-only users. If your team includes people who cannot use a mouse, that is a question for the demo instance, not for this text.
Getting an instance running with Docker Compose
The recommended path is four steps. Fetch the compose file, edit its environment variables, start it, log in.
curl -L https://raw.githubusercontent.com/RARgames/4gaBoards/main/docker-compose.yml -o docker-compose.yml
Then edit the environment sections inside docker-compose.yml. The README names four variables to change: BASE_URL to your domain or IP, SECRET_KEY to a random value generated with openssl rand -hex 64, and both POSTGRES_PASSWORD and DATABASE_URL so the notpassword placeholder is replaced with a real database password. The linked page at docs.4gaboards.com/docs/dev/install/docker-vars is where the rest of the variables live, and the README does not reproduce them.
Start it with docker compose up -d. The default URL is http://localhost:3000 and the default login is demo / demo. Changing those credentials is not described in the README excerpt, so treat the demo account as something to deal with before the instance is reachable from the internet.
For development, the sequence is git clone, pnpm i, then cp server/.env.sample server/.env. Building the client is optional and exists to suppress startup warnings: pnpm client:build, followed by copying client/build into server/public and client/build/index.html to server/views/index.ejs. A development database comes from docker compose -f docker-compose-dev.yml up -d, or you point DATABASE_URL in server/.env at your own PostgreSQL. Initialise with pnpm server:db:init, then run pnpm dev.
The Kubernetes, TrueNAS and manual installation paths are listed as links only. If you are not using Docker Compose, this README sends you to the documentation site rather than answering the question here.
Backup, restore, and the password trap in the restore script
Two shell scripts ship with the deployment: ./boards-backup.sh produces a 4gaBoards-backup.tgz, and ./boards-restore.sh takes that file as an argument. The README says to change into the directory containing docker-compose.yml before running either, and that relative paths are fine.
The restore documentation contains the most specific operational warning in the whole README. The password used at restore time has to match the password in docker-compose.yml. If you have forgotten the original, you can set a new one in the compose file, but then you must skip the line in the backup that alters the default user. The README quotes that line: ALTER ROLE postgres WITH SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN REPLICATION BYPASSRLS PASSWORD 'XXX'. Comment it out inside backup.tgz/postgres.sql before restoring.
That is a real constraint, and it tells you something about the backup format: it is a PostgreSQL dump wrapped in a tarball, not an application-level export. Restoring therefore rewrites roles, which is why the password has to line up. Anyone treating these scripts as a simple file copy will hit the mismatch on the first restore attempt, and the failure will surface as a database authentication error rather than a clear message about the cause.
The practical implication is that the database password belongs in whatever secret store you already use, because a restore months from now depends on reproducing it or on editing a SQL file by hand.
Importing from Trello, and what the import does not carry
Trello migration is built in. The README says to add a project, then click Import while creating a new board. No separate CLI, no export file to parse by hand, no third-party script. For a team already living in Trello, that is the shortest path to a populated instance, and it is the feature most likely to decide the adoption question.
The README stops there. It does not say whether attachments, comments, checklists, labels, archived cards or member assignments survive the import, and it does not describe what happens when a board exceeds whatever size limit the importer assumes. Those are exactly the details that determine whether an import is a five-minute job or an afternoon of cleanup, and none of them are answerable from the supplied material. Test the import with one real Trello board before promising a migration date to anyone.
The export side is better served on paper: Export/Import Boards is listed as a feature, so boards can leave the instance in some format. Whether that format is JSON, CSV or something else is not stated. If portability matters to you, confirm the format before you rely on it.
Where 4ga Boards is the wrong choice
Three limitations stand out.
First, the integration surface is thin. GitHub two-way sync is marked coming soon, and the README describes no public API, no webhooks and no CLI. If your workflow depends on issues moving between a code host and a board automatically, this project does not do that today, and the README gives no date.
Second, the documentation is split. The README covers deployment, backup and development. Everything else (instance variables, web server configuration, SSO, web server proxying) is a link to docs.4gaboards.com, in English and Polish. If you need an air-gapped install or an offline copy of the docs, the material here does not tell you whether that exists.
Third, PostgreSQL is not optional. The stack is Sails.js and Knex.js against PostgreSQL, and the development instructions assume either the bundled docker-compose-dev.yml database or your own DATABASE_URL. A team standardised on MySQL or SQLite cannot swap the database out without code changes.
The upgrade path is the quietest gap. Releases are frequent (v3.3.11, v3.3.12 and v3.3.13 all landed within a fortnight in July 2026), but the README does not describe a migration procedure, does not name an image tag to pin, and does not say whether server:db:init is safe to re-run against an existing database. Frequent releases plus an undocumented upgrade path is a combination that rewards testing on a copy first.
How it differs from Planka and Focalboard
Both Planka and Focalboard occupy the same slot: self-hosted kanban, MIT or similar permissive licensing, container deployment. The differences that matter are in the details, and the material here supports a few concrete comparisons.
Focalboard arrived from the Mattermost ecosystem and, in its standalone form, has been positioned as a Notion-style document and board tool, with boards as one view over a database of cards rather than the primary object. 4ga Boards commits to the opposite model: the hierarchy is projects, boards, lists, cards, tasks, with the board as the organising surface. If your team wants a wiki with a board attached, Focalboard's shape fits better. If you want the board to be the whole product, 4ga Boards is closer.
Planka is the nearer match: a Trello-style board, PostgreSQL, Docker Compose, realtime updates. The distinguishing claim in this README is the multitasking behaviour, where a description edit survives while the board is filtered and rearranged underneath it, and the collapsible lists and sidebar for large projects. Those are usability decisions rather than architectural ones, and the honest way to judge them is to open the demo at 4gaboards.com/try and drag a card around while someone else edits it.
What none of these comparisons settle is migration cost between them. 4ga Boards imports from Trello, not from Planka or Focalboard, and the README lists no importer for either.
Licence, maintenance and what to check before you commit
The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are kept. This is not legal advice, and the repository's LICENSE file is the authority, but the practical consequence is that forking for internal changes carries no copyleft obligation and no separate commercial tier is mentioned in the material that would restrict self-hosting.
The maintenance picture visible here is active: the repository is not archived, the last push is dated 2026-09-09, and three patch releases (v3.3.11, v3.3.12, v3.3.13) appeared in July 2026. The README lists two main maintainers, RARgames and wilkobyl, and points to a Discord, a contribution page and a donation page where donors can attach an email and ask for a feature to be prioritised. That last detail is worth knowing: feature priority is partly a function of funding, which is a normal arrangement for a small project but shapes what gets built next.
Upgrade cost is the item to budget for. Because the README documents no migration command beyond pnpm server:db:init and no image tag to pin, a version bump means reading the release notes, taking a backup with ./boards-backup.sh, restoring into a staging copy, and confirming the schema still matches before touching the instance your team uses. The backup and restore scripts make that loop possible. Nothing in the material makes it automatic.
Editorial conclusion
Adopt 4ga Boards if you want a self-hosted kanban board with a documented Docker Compose path, a Trello import step inside the board creation flow, and an MIT licence that lets you modify the code. Do not adopt it if you need GitHub issue sync, a published HTTP API reference, or an upgrade procedure that is documented rather than inferred from the repository. Before you commit, verify three things on a throwaway instance: that ./boards-backup.sh and ./boards-restore.sh round-trip your data with the POSTGRES_PASSWORD currently in docker-compose.yml, that your reverse proxy forwards WebSocket upgrades so the realtime updates actually reach the browser, and that a tagged image exists for the version you pin, because the README pulls images without naming a tag.
Community notes