v0.1.1 — Tinker credentials end-to-end

First release after introducing the stable branch convention. Production deploys now track stable (this tag). Daily work continues on main.

Highlights since v0.1.0

Tinker API credentials (end-to-end)

• Encrypted storage at rest (AES-256-GCM via node:crypto with the auto-generated ENCRYPTION_KEY).
• Live validation against the Tinker worker: /tinker/validate calls ServiceClient().get_server_capabilities_async() with a 20s asyncio.wait_for ceiling so the SDK's silent retries can't hang the UI.
• Errors are classified and surfaced as clickable links (e.g. 402 → https://tinker-console.thinkingmachines.ai/billing/balance).
• Key is persisted even when validation fails, so the user can fix billing/network and click Revalidate without re-typing.

Framework / infra

• Renamed middleware.ts → proxy.ts (Next.js 16 convention); auth() still enforced at the page level as defense in depth.
• Initial Prisma migration committed at prisma/migrations/0_init/.
• Documented SSH update flow with --no-cache, --remove-orphans, and docker image prune -f.
• Added CLAUDE.md so future sessions land with the right deploy/ops constraints.

Branch model going forward

• main — active development, may break.
• stable — production-ready; advances when a release is cut.
• Pre-releases (vX.Y.Z-beta.N) cut from main for semi-ready cuts.

See README.md → Updating to a New Version for the new SSH deploy flow (git pull origin stable).

v0.1.0 — First deployable release - Authentication

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.