Skip to content

v0.1.0 — First deployable release - Authentication

Choose a tag to compare

View all tags
@danielbfs danielbfs released this 14 May 20:26
v0.1.0
d2c6639

First production-ready cut of EaseTinker. The full Next.js + Auth.js + Prisma + Docker
stack runs end-to-end on a Hostinger VPS behind Traefik, with technical secrets that
generate themselves on the first boot.

What's in this release

Auth

  • Auth.js v5 (next-auth 5.0.0-beta.31) with Google and GitHub OAuth providers
  • Server-side session check on every protected route (root / and /projects)
  • Middleware redirect for unauthenticated traffic
  • AUTH_TRUST_HOST=true baked into compose so Auth.js accepts the forwarded host
    when running behind a reverse proxy

Database

  • PostgreSQL 16 (Alpine) with POSTGRES_PASSWORD_FILE for password injection
  • Prisma 6.16+ ORM
  • prisma migrate deploy works inside the runner container

Worker

Worker

  • Python FastAPI service over BullMQ on Redis
  • Shared-secret auth between Next.js and the worker

Deploy

  • Multi-stage Dockerfile with Next.js standalone build + Prisma CLI shipped in runner
  • Docker Compose stack: init-secrets, app, worker, postgres, redis
  • Traefik labels for HTTPS/Let's Encrypt (works with Traefik in either bridge or host mode)
  • .gitattributes pins LF line endings so shell scripts survive Windows clones

The big new thing: auto-generated technical secrets

Four technical secrets used to be hand-rolled on every fresh deploy
(POSTGRES_PASSWORD, NEXTAUTH_SECRET, ENCRYPTION_KEY, WORKER_SECRET).
Now an init-secrets compose service runs once on first boot, generates them
via openssl rand, and persists them in the secrets named volume.
A thin entrypoint script (docker/docker-entrypoint.sh) loads them into env vars
when the app and worker start. Subsequent deploys reuse the same files —
no rotation, no broken sessions, no migration-blocking password mismatch.

A fresh Hostinger deploy now only needs APP_DOMAIN plus OAuth keys in .env.

Deploying this version

See README.md (or docs/README.pt-BR.md) for the full walk-through. TL;DR for Hostinger:

  1. Point your domain at the VPS.
  2. Deploy via Hostinger Docker Manager pointing at this tag.
  3. Fill in APP_DOMAIN, GOOGLE_CLIENT_* and/or GITHUB_CLIENT_* in the project's .env.
  4. After the stack boots, run migrations: 
    docker compose -p easetinker exec app /usr/local/bin/docker-entrypoint.sh pnpm exec prisma migrate deploy

Known limitations

  • The starter is currently a single repo — a generic
    nextjs-auth-docker-starter template is on the roadmap (ROADMAP.md).
  • The middleware.ts convention is deprecated in Next.js 16 (still works,
    but emits a warning at build time); migrating to proxy.ts is a follow-up.
  • No tests yet.

Quer que eu marque o repo como Template Repository também? Isso é via GitHub Settings → "Template repository" (não há gh flag pra isso, é botão na UI). Se ativar, o repo passa a oferecer "Use this
template" pra criar novos projetos a partir dele — bom pra reuso futuro mesmo antes de a gente extrair o starter limpo.

Assets 2
Loading