Self-hosting
The collector, the database and the dashboard are one repository and one Compose stack. Running it yourself is supported, and it is the answer when data residency or an enterprise review rules out the hosted service.
Beta
Self-hosting works and is what the maintainers develop against daily, but it is not yet packaged as versioned images. You build from source.
What you need
- Docker, with Compose
- Node 24 and pnpm 11, to build and to run migrations
- A domain with TLS, if anything outside your own network will send events
Bring it up
git clone git@github.com:deasil-org/analytics-trend.git
cd analytics-trend
cp apps/api/.env.example apps/api/.envGenerate a session key and paste it into SESSION_SECRET in that file:
node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"Then install, start Postgres and migrate:
pnpm install
docker compose up -d postgres
pnpm --filter api prisma:migrateRun the collector and the dashboard:
pnpm dev:api # collector and read API on port 8000
pnpm dev:web # dashboard on port 5173Create an account
Signup is invite-gated even on your own instance, because the gate is a property of the product rather than of the hosted service. Mint yourself a code:
pnpm --filter api invite 1Create a project from the dashboard, then point your SDK at your own collector:
init({ writeKey: "wk_...", endpoint: "https://analytics.example.com" });What to watch
The signal that matters at scale is Postgres write latency under ingestion, not container count or request rate.
Daily rollups run hourly inside the collector process, and once at startup so a freshly started instance is not blank for an hour. Raw events are pruned after 90 days while the daily rollups and per-user-day rows are kept indefinitely, so history survives even after the detail ages out.
What you are responsible for
Backups of the Postgres volume, TLS termination, and keeping SESSION_SECRET secret. The database is never shared with anything else: its own container, its own volume, its own backup and its own restore.