Two env files disagree about secrets, and the object store publishes no port

The compose stack refuses to start without seven values the example file ships anyway

Two files, two postures. The compose file names the values it will not start without: `POSTGRES_PASSWORD`, `BETTER_AUTH_SECRET`, `APP_ENCRYPTION_KEY`, `S3_ACCESS_KEY_ID`, `S3_SECRET_ACCESS_KEY`, `API_URL` and `APP_URL`, with the instruction to generate each secret using `openssl rand -base64 32`.

The example env file, which is also what local development reads, takes the opposite approach. It ships `POSTGRES_PASSWORD=itsaplan`, a `DATABASE_URL` with that same password written into the connection string, and `BETTER_AUTH_SECRET=change-me-please-generate-a-real-secret`. Its own comment says development works with those values as they stand, except for the secrets marked as needing to be generated.

So the same repository contains a file that will refuse to run without real secrets and a file that will run happily with the placeholder ones. Anyone copying the example into a self-hosted deployment inherits a known password and a known auth secret unless they change both, and the compose file's check does not catch the placeholder, only the absence.

Two other settings are worth knowing because of when they take effect. The passkey relying party defaults to the `APP_URL` hostname, and the legal document URLs are read by the web app at startup, so changing them needs a restart rather than a rebuild.

The object store has no published port on purpose

Attachments live in RustFS, an S3-compatible store, and the compose file is explicit about how it is exposed. Both the S3 API on port 9000 and the console on port 9001 stay inside the compose network, and no port is published for either. The api streams attachment bytes through itself rather than redirecting a browser at the store.

The consequence is that the object store is unreachable from outside the host. Administration goes through an S3 client from inside the network, or through an SSH tunnel. That is the right default for an instance holding issue attachments, and it also means a deployment that expects to point an external backup tool at the store URL will not work without opening a port.

The comment explaining the naming of the service and its volume stops one word into a comparison with another product, after saying that both keep the names of the earlier project. Nothing else on the page describes the store's configuration, its persistence beyond the named volume, or what happens to existing attachments when an instance is moved.

Six services, four of them published as images on every release

The self-hosting stack is described in the compose file's own header as postgres plus rustfs plus api, worker, bot and web. The database is `postgres:17-alpine` with a named volume, a healthcheck running `pg_isready` every five seconds, a five second timeout and ten retries before it is considered up.

The four application services run from images published on each release, and updating is `docker compose pull` followed by `docker compose up -d`. The `VERSION` value in the env file pins a release and defaults to the latest, which is the mechanism to reach a specific one. To run a checkout rather than the published images, the same command takes `--build`.

There are five compose files at the root, not one: the main stack, a Coolify variant, a Coolify variant that uses prebuilt images, a development file that brings up backing services only, and a test file. The development and test paths are wired into the package scripts, including a test migration that sets `SKIP_PRE_MIGRATION_BACKUP=1` to bypass the pre-migration backup step.

The local route avoids Docker images entirely and asks for Docker plus Bun:

git clone https://github.com/croffasia/itsaplan.git
cd itsaplan
bun install
bun run setup   # answer "Try it"

That setup step is what generates the secrets and picks free ports, and it is interactive, which means an unattended container build has nothing to answer.

Agents are project members, and the tracker is complete without them

The clearest statement about scope is that the product is a full issue tracker on its own, with projects, boards, cycles, custom fields and dashboards, and the page invites you to use it that way and never turn on a single agent. Agents are the difference, not the foundation.

When you do enable them, an agent is a project member: it gets a role, its own permissions, and an assignee slot on the same board as people. There are three ways to run one. An internal agent runs on the instance with a model, a system prompt, tools, and reusable skills written inline or imported from a GitHub repository. An external agent runs on your own machine under your own account, installed as `@itsaplan/runner`, which hands every task to Claude Code, Codex, Antigravity CLI, GitHub Copilot CLI, opencode, or any command that reads standard input. Or you take over the run queue through the API and do the work in your own implementation.

A run starts on an @mention in a comment, on an assignment, or on a schedule. The built-in tool set covers Notion, Telegram, Threads, Instagram, Jina, Firecrawl and Gitea, each agent has its own chat history, and chatting with an external agent resumes the same coding session on each message rather than starting a fresh one.

Public read-only links need no sign-in

Sharing is a first-class feature and one line of it deserves attention from anyone self-hosting: a view or an issue can be shared by public link, read-only and without sign-in. That is the intended behaviour, not an oversight, and it is the mechanism behind the page's claim that you can show progress without deploying anything.

Set against it is a set of controls that show the same feature thought through. Docs pages come in three states, public, private and locked, with revision history and the ability to embed files and link to the issues they describe. There is role-based access control, an auto-archive rule, a notification inbox, and an instance administration area covering storage limits, mail transport and instance-wide settings. Sign-in accepts email or username plus password, a passkey, or Google.

For a tracker holding internal plans, the audit question is therefore specific: which projects have public sharing enabled, and are any of them carrying links that were only meant for a colleague. Nothing on the page answers that, which is exactly why it is worth asking before the first invite.

Nine interface languages, automated releases and a telemetry file

The interface ships in nine languages: English, Ukrainian, Russian, Simplified Chinese, Arabic, French, Portuguese from Brazil, Bahasa Indonesia and Spanish from Spain.

The repository is a Bun workspace with `apps/*` and `packages/*`, driven by turbo for dev, build, start and lint, with lefthook for hooks and Prettier for formatting. Releases come from a release-please configuration with a matching manifest, so the version in the root manifest tracks the tags. The manifest records the license as AGPL-3.0-only while the repository record and the license badge say AGPL-3.0, a difference in wording that is worth checking if you redistribute.

Among the root files are two whose presence says something. `TELEMETRY.md` exists, so the question of what the instance reports upward has a written answer somewhere in the tree. `ICLA.md` sits next to `CONTRIBUTING.md` and `CODE_OF_CONDUCT.md`, which is not a filename this project explains anywhere on the page. There are also agent-tool directories, an AGENTS.md and a CLAUDE.md at the root alongside DESIGN.md.

The dependency pins are equally deliberate: four overrides hold `@scalar` packages and two Tiptap menu extensions at exact versions rather than ranges.

Two tags seventy minutes apart, and a stated expectation of breakage

The recent tags are v1.1.0 on 2026-09-23, then v1.2.0 and v1.2.1 on 2026-09-26, the second seventy minutes after the first. The root manifest reports 1.2.1, which matches the newest tag, and the repository's last recorded push is 2026-10-02, after all three.

Against that cadence the page states its own maturity plainly: the project is under active development and breaking changes are to be expected before a first stable release. Read next to the tag timestamps, that is a project on a fast release rhythm rather than one waiting for a 1.0, which is an argument for pinning rather than for avoiding the software.

The funding arrangement is also part of the project's design rather than an afterthought. Alongside asking for stars, shares and pull requests, the page asks for donations and says a donation can move a feature up the roadmap, with the request routed through Telegram. Three wallet addresses are published, for USDT on ERC-20, TON and TRC-20.

Deployment has a recommended path too: a one-click Railway template that generates every secret in exchange for two hostnames and a domain of your own, plus Coolify and plain self-hosting guides.

Editorial conclusion

It's a Plan is worth evaluating if you want an issue tracker you host, and if the agent side is a feature you would use rather than one you have to switch on. The project makes that optional by design, so the base product stands on its own. Four things to settle before you deploy it. The agents are the part with the widest blast radius: an internal agent runs with tools and skills inside your instance, and an external one executes a coding CLI on your own machine under your own account, so decide which of the two models you actually want before enabling either. Second, read both environment files. The compose stack refuses to start without seven values, while the local example ships a default database password and a placeholder auth secret, and copying the wrong one to the wrong place is the most likely first mistake. Third, note that sharing is built in: a view or an issue can be published as a public read-only link with no sign-in, which is a deliberate feature and also the thing to audit on a shared instance. Finally, the page says to expect breaking changes before a first stable release, and two of the three recent tags landed about seventy minutes apart, so pin a release by the VERSION value in your env file rather than tracking latest.

Frequently asked questions

Official sources

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