Nextcloud Deck: a Trello-style kanban board that lives inside your Nextcloud

What Deck adds to a Nextcloud instance

Deck is a kanban board that runs as a Nextcloud app rather than as a separate service. The README describes it as "a kanban style organization tool aimed at personal planning and project organization for teams integrated with Nextcloud". Cards hold tasks, they can be reordered within a stack, and the description field accepts markdown. Labels, comments, file attachments and an activity stream are all part of the card. Sharing is handled through Nextcloud, and the README also lists an integration with the Circles app. The audience is therefore narrow and specific: people who already have a Nextcloud account and want their task board to sit behind the same login, on the same storage, under the same sharing rules. If your team does not run Nextcloud, Deck is not a standalone product you can install on its own. The repository is a Nextcloud app (appinfo/, lib/, src/, templates/), and the README's installation section points at the app store inside Nextcloud or the release page. That coupling is the whole value proposition and also the whole constraint.

How a card becomes a board: the mechanism

The architecture follows the standard Nextcloud app pattern. The frontend is a Vue application built by webpack; package.json pulls in @nextcloud/vue, @nextcloud/axios, @nextcloud/router and @nextcloud/initial-state, which is how a Nextcloud app receives server-side data before the JavaScript bundle takes over. Markdown rendering uses markdown-it with markdown-it-task-checkbox, so checkbox lists inside a card description are interactive, and markdown-it-link-attributes controls how links behave. dompurify is present, which matters because card descriptions and comments are user-supplied HTML after rendering. frappe-gantt appears among the dependencies, so the repository contains gantt-style rendering in addition to the board view. On the server side, lib/ holds the PHP application code and appinfo/ holds the app manifest, routes and database schema. The data flow is: browser loads the Nextcloud page, initial state is injected, the Vue app talks to the Deck REST API over @nextcloud/axios, and the PHP backend reads and writes through Nextcloud's database layer. The README points to the REST API documentation at deck.readthedocs.io, which is the surface third-party clients build against, and the mobile apps listed in the README (an Android client by stefan-niedermann and an iOS client called nextdeck) are exactly that kind of client.

Installing Deck and creating a first board

The README gives two installation routes: the app store inside Nextcloud, or the release page at github.com/nextcloud-releases/deck/releases. Nothing else is required for a normal instance. Once the app is enabled, Deck appears in the Nextcloud app navigation.

If you are developing against the app rather than just using it, the general build instructions require Node.js and Composer. Install the PHP dependencies first, then the JavaScript dependencies, then build the frontend:

composer install --no-dev
npm ci
npm run build

The README documents npm run dev for a development build and npm run watch to rebuild on changes. For frontend work there is a hot module replacement path: install and enable the hmr_enabler app, run npm run serve, then open the normal Nextcloud server URL rather than the URL the command prints.

There is also a Docker route that mounts the app source into a Nextcloud development container:

docker run --rm \
    -p 8080:80 \
    -v $PWD:/var/www/html/apps-extra/deck \
    ghcr.io/juliushaertl/nextcloud-dev-php81:latest

The README says to fork and clone the repository, build the app as described above, and then run that container with the source mounted at apps-extra/deck. The container exposes port 8080. GitHub Codespaces and a VS Code devcontainer are also documented: the container installs dependencies, builds the app, and installs Nextcloud from the master development branch. Tests run through the Makefile with make test, which the README describes as running all tests.

The performance ceiling the README admits

The most useful section of the README is the one titled "Performance limitations", and it is unusually blunt: "Deck is not yet ready for intensive usage." The explanation is that a lot of database queries are generated when the number of boards, cards and attachments grows. The README gives a worked example. A user with access to 13 boards, each board averaging 100 cards, and each card averaging 5 attachments, would generate 6500 database queries when doing the file related queries, which the README says would increase page loading time significantly. It then states that improvements on the Nextcloud server and in Deck itself will improve the situation, which is a statement about future work, not a current fix. Read that as a sizing rule. A small team with a handful of boards and few attachments will not notice. A department that imports years of Trello history, attaches files to most cards, and expects instant board loads is exactly the workload the README warns against. The attachment count is the multiplier that matters most, because attachments are what trigger the file related queries. If you are evaluating Deck, the honest test is to measure board load time with your real attachment volume before rolling it out, not after.

Trello import, mobile clients and third-party integrations

Deck does not ship a Trello importer in the repository. The README lists trello-to-deck as a third-party integration that "Migrates cards from Trello", which means migration depends on an external project you have to evaluate separately. The same list includes mail2deck for an email-in workflow, A-deck, a Chrome extension that creates a card in a selected stack from the current tab, and QOwnNotes, which creates cards and links to them from markdown notes. None of these are maintained by the Deck repository. Mobile access is also third-party: the README links an Android app available in F-Droid and the Google Play Store, and an iOS app called nextdeck on the Apple App Store. Both are separate repositories with their own release cycles, so a Deck server upgrade can outpace the client you rely on. The API documentation at deck.readthedocs.io is the contract those clients use, and it is the right place to check before assuming a feature exists on mobile. For a team already standardized on Nextcloud, the integration story is the reason to pick Deck. For a team that wants a single vendor behind web, mobile and migration tooling, the split ownership is a real operational cost.

Deck against Nextcloud Tasks and against Trello

The closest thing inside Nextcloud is the Tasks app, and the difference is the data model. Tasks produces a flat list of items with due dates that surface in the Nextcloud calendar and in CalDAV clients. Deck produces boards with stacks and cards, and its cards are not calendar entries. If your workflow is "what do I owe this week", Tasks is the smaller tool and it interoperates with anything that speaks CalDAV. If your workflow is "what is in progress, what is blocked, what is done", Deck's stacks carry that state and Tasks does not. The comparison with Trello is about where the data lives. Trello is a hosted service with its own mobile apps, its own importer and its own scaling story; Deck is an app you install into a Nextcloud you operate, with the performance caveat above and third-party clients. The README's own framing, "similar to Trello" in the repository description, is fair about the interaction model and silent about the hosting trade-off, which is the part that actually decides the choice. A self-hosted Trello-shaped board is worth the operational work only if keeping the cards on your own server is a requirement rather than a preference.

Licence, contribution terms and upgrade cost

Deck is licensed AGPL-3.0, and the README states that all contributions are considered licensed under the GNU AGPLv3 or any later version. Contributors keep their copyright, and the README recommends adding a copyright line to any file changed substantially. Commits must carry a Developer Certificate of Origin sign-off, which the README shows as a Signed-off-by line with a real name, and notes that git commit -s adds it automatically from your git config. For anyone embedding Deck in a product, AGPL-3.0 is a network copyleft licence, so the obligations attach to users interacting with a modified version over a network. That is a question for your own legal review, not something this article can settle. On upgrade cost: the repository carries a CHANGELOG.md, and the recent release list shows parallel maintenance branches, with v1.18.4 and v1.17.5 published alongside a v1.19.0 beta. That pattern means you pick the release line that matches your Nextcloud server version rather than always taking the newest tag. The last push to the repository was on 2026-08-27. Upgrading is an app-store update or a manual release install, and the practical risk sits in the database migrations and in whether your mobile client supports the new server version.

Editorial conclusion

Deck fits teams that already run Nextcloud and want boards, comments and file attachments in the same account and on the same server, without a separate SaaS subscription. It does not fit anyone who needs a kanban tool at scale: the README states Deck is not yet ready for intensive usage and gives an example where 13 boards averaging 100 cards and 5 attachments per card produce 6500 database queries for the file related queries. Before adopting it, check the release notes for the branch that matches your Nextcloud server version, confirm the Android or iOS app you intend to use supports that server version, and read the performance section of the README against your own board and attachment counts.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes