Ideon: a self-hosted infinite canvas for project context

Replacing folders with positions on a canvas

Ideon is a self-hosted visual workspace. The README frames the problem plainly: a project is scattered across too many tools, and the application puts notes, files and to-dos together on an infinite canvas. The organising idea is spatial rather than hierarchical. Instead of navigating a folder tree, you place blocks anywhere, and the rule is that what is close is related.

The feature list is what makes it a workspace rather than a whiteboard. Live integrations embed repositories and issues directly on the canvas from GitHub, GitLab, Gitea and Forgejo. Rich media covers Markdown notes, rendered Mermaid diagrams, images, links and files. Multiplayer gives real-time collaboration with a team. Time Travel exposes historical snapshots of a workspace so you can trace how a decision was reached. Git Versioning syncs a project canvas to a Git repository, with notes and structure stored as versioned files. And the whole thing is self-hosted, so the README says you own your data.

That last point is the reason a project like this exists at all. The hosted tools in this category keep your notes and task structure on someone else's servers. Ideon gives you the same shape of tool running inside your own network, and the price is that you now operate a database, a container image and an upgrade path.

The repository is a TypeScript project with a Next.js front end, a src directory holding the application, a Dockerfile, a compose.sh helper, husky hooks, a .pre-commit-config.yaml, commitlint, eslint, tailwind, vitest and a tsup build for the server bundle. Documentation lives at the site under /docs/, and there is a Discord server and a public roadmap board for the project.

The Compose stack is one app container and one PostgreSQL

Deployment is a two-service Docker Compose setup, and the published docker-compose.yml is short enough to read in full. The app runs from the image ghcr.io/3xpyth0n/ideon:latest, reads its configuration from an env file, and depends on the database service being healthy before it starts:

    ports:
      - "${APP_PORT:-3000}:${APP_PORT:-3000}"
    volumes:
      - ideon-app-data:/app/storage
    healthcheck:
      test:
        ["CMD", "curl", "-f", "http://localhost:${APP_PORT:-3000}/api/health"]

The port mapping defaults to 3000 on both sides and is overridable through APP_PORT, so the same stack can be published on a different host port without editing the file. The named volume ideon-app-data is mounted at /app/storage, which is where the container keeps persistent state, and the database gets its own volume at /var/lib/postgresql/data. The app healthcheck polls the /api/health endpoint with curl every five seconds, with a timeout of five seconds, five retries and a ten second start period, and the database healthcheck uses pg_isready against the configured user and database every two seconds. The app service is set to restart unless-stopped.

The database is postgres:18-alpine, and its credentials come from the environment as DB_USER, DB_PASS and DB_NAME, with PGDATA pointed at a subdirectory of the volume. The app container also accepts optional PUID and PGID values for file ownership, defaulting to 1001. That default is not arbitrary: the Dockerfile creates a user with uid 1001 and chowns /app/storage to it, so if you change the container user you have to change the volume permissions with it.

Getting started takes an env file and one compose command

The README asks for Docker and Docker Compose, and then for three steps. Clone the repository, or download docker-compose.yml directly. Copy the environment template:

cp env.example .env

Then edit .env and set at minimum SECRET_KEY, which the README says to generate with openssl rand -hex 32, along with any database credentials you want to change. The env file is wired into Compose through env_file with a default of ${ENV_FILE:-.env}, so a different file can be passed in for a staging deployment without editing the Compose file itself. Finally, start the stack:

docker compose up -d

With the stack up, the dashboard is served at http://localhost:3000. The Compose file's env_file setting means that a .env file must exist before the app container starts, and the app will not become healthy without a valid SECRET_KEY, so a first run that shows a restarting container usually means the env file is missing a value rather than that the image is broken.

There is a faster path for people who already run Docker hosting platforms. The README documents a one-click Easypanel template, and the template sets up the required PostgreSQL database and a persistent volume for /app/storage automatically. That is the sensible route for a first evaluation, since it removes the hand-editing of .env, though it also moves the configuration into a control panel rather than a file you can keep in version control.

Where the code lives: Next.js, tsup and an 8 GB heap

The package.json scripts show how the application is put together. The build is a Next.js build followed by a tsup bundle, the dev command drives the Compose file directly, and the check script runs eslint with zero warnings allowed plus a TypeScript check with no emit:

  "scripts": {
    "dev": "./compose.sh build && ./compose.sh restart",
    "build": "next build --webpack && tsup",
    "start": "NODE_OPTIONS='--max-old-space-size=8192' node dist/server.cjs",
    "check": "eslint . --max-warnings=0; tsc --noEmit",
    "test": "vitest run",

The start script is worth pausing on. The server runs with a maximum old space size of 8 GB, which tells you the server bundle holds a lot in memory, plausibly because collaborative editing sessions and canvas state are held server-side. On a small host that heap reservation is not a real allocation, but it does mean the process expects room to grow.

The Dockerfile is a three-stage build on node:24-slim. The builder installs the dependencies and runs the production build, a separate server-runtime stage installs a small set of packages that the traced node_modules misses, and the runner stage copies the standalone Next.js output, the tsup dist directory, the scripts directory, the static assets, the public directory, the i18n sources and the database migrations into a final image that runs under tini with a non-root user. The runtime stage also installs git, qpdf and curl, which suggests PDF export and Git operations happen inside the container rather than being delegated to the host.

The dependency list explains the feature set. CodeMirror language packages cover the code block types, Tiptap supplies the rich text editor, dnd-kit handles drag and drop, Excalidraw is the drawing surface, y-leveldb is the Yjs storage layer behind multiplayer, Kysely is the query builder, node-pty gives a terminal, pdfkit handles PDF generation, React Email handles mail, and the Model Context Protocol SDK is present, which points to the workspace being reachable by an AI agent over MCP.

Version 1.0.0, a busy release line and an AGPL licence

The project reached a first stable tag recently. Version 1.0.0 shipped on 2026-10-15, preceded by 0.9.8 on 2026-10-01 and 0.9.7 on 2026-09-26, and the last push was on 2026-10-15. Three releases in three weeks, with a 0.9 series still running right up to the 1.0 tag, is the pattern of a product that was in beta for most of its life and only just settled its public API. The package version in package.json is 1.0.0 and the package is marked private, meaning it is not published to a registry for general consumption.

The licence is AGPL-3.0-or-later, stated in the package.json license field, in the README and in the badge. For a self-hosted tool that only your own team uses over your own network, the AGPL obligations are not usually the deciding factor. If you expose a modified version of Ideon to users over a network, the copyleft terms reach further than a permissive licence would, and that is the scenario to think about before you build a hosted service on it. The repository also ships a SECURITY.md, a CODE_OF_CONDUCT.md, a CONTRIBUTING.md and a CHANGELOG.md, so the project has the process documents a community-facing project is expected to have.

The creator is Saad Idrissi, and the README credits a contributors list that includes security reviewers and translators, with the project following the all-contributors specification. The site is theideon.com, with a documentation section, an about page and a public roadmap hosted as a GitHub project board.

Where a canvas is the wrong shape for the job

A spatial canvas is excellent for thinking and mediocre for storage. Everything you place is positioned by hand, which means positions are a piece of information that only exists in the workspace itself, and the Git versioning feature exists precisely to get the notes and structure into files. If your team's actual needs are a queryable backlog, a report on issue throughput, or a database other tools can read, a canvas is the wrong shape, and a project management tracker with a good API will serve you better.

The deployment requirements are the second constraint. Docker and Docker Compose are mandatory, you need a PostgreSQL instance, and the app container expects to own /app/storage with a specific uid. Nothing here runs from a single binary, and there is no documented way to run Ideon without the Compose stack. For a personal machine that is fine. For a locked-down environment where containers are not approved, it rules the tool out.

The third constraint is the freshness of the 1.0 release. The README does not document a backup or restore procedure for the Postgres volume, an upgrade path between 0.9 and 1.0, or how canvas history is pruned as snapshots accumulate. A tool that stores project history in snapshots you cannot easily export is a risk to plan for, and the repository's own documentation does not yet answer how to move data out of it. For a trial on a side project that is fine. For the system that holds your team's planning, you want to see the export path first.

Editorial conclusion

Ideon suits a team that wants one shared, visual surface for the repositories, notes and tasks of a project and is comfortable running a Docker Compose stack with a PostgreSQL database behind it. It is a poor fit as the system of record for structured project data, and it is a poor fit for a company unwilling to run AGPL-3.0 software over a network for its users. Before deploying, set SECRET_KEY with openssl rand -hex 32, change the database credentials in .env, and check the healthcheck path /api/health and the APP_PORT variable, since the published image listens on port 3000 by default.

Frequently asked questions

Official sources

1. 3xpyth0n/ideon on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases