App candidate staging

Stato

Le app elencate hanno container running sul droplet e sono candidate allo staging VPS.

Non considerarle produzione migrata: la produzione resta su Vercel/hosting esistente finche' la singola app non e' verificata e migrata esplicitamente.

Target staging:

<app>.vps.obelica.com -> 129.212.141.97

Stato TLS: completato il 2026-06-22 per i domini staging *.vps.obelica.com.

Smoke test globale staging: completato il 2026-06-22 con 96 OK, 0 WARN, 0 UNKNOWN, 0 FAIL anche dopo rebuild e recreate completo delle app staging.

Standard Docker app staging dal 2026-06-22:

• ogni repo app deve avere .dockerignore;
• i Dockerfile npm devono usare cache BuildKit per /root/.npm;
• i Dockerfile pnpm devono usare cache BuildKit per lo store pnpm;
• la build context non deve includere .git, node_modules, .next, .vercel, cache locali, log, editor config o file .env;
• le immagini vanno ricreate con docker compose up -d --build --force-recreate;
• dopo il rebuild completo eseguire sempre obelica smoke staging;
• dopo build massive e' normale fare docker builder prune -f per recuperare cache ricostruibile.

I router Traefik delle app candidate devono usare solo il dominio staging:

Host(`<app>.vps.obelica.com`)

Non usare regole miste tipo Host(<app>.obelica.com) || Host(<app>.vps.obelica.com) durante la fase staging: Let's Encrypt prova a validare entrambi gli host nello stesso ordine e fallisce se il dominio produzione resta su Vercel.

Schede tecniche

Operazioni comuni

Ricostruire un'app

cd /opt/obelica/repos/<app>
docker compose up -d --build --force-recreate

Vedere i log

cd /opt/obelica/repos/<app>
docker compose logs --tail=100 -f

Verificare lo stato

cd /opt/obelica/repos/<app>
docker compose ps
obelica smoke staging

Policy log Docker

Tutte le app candidate staging devono limitare i log container:

logging:
  driver: "json-file"
  options:
    max-size: "10m"
    max-file: "3"

Policy build Docker

Ogni app staging deve avere un .dockerignore con almeno:

.git
.env
.env.*
node_modules
.next
dist
build
.turbo
.vercel
.cache
coverage
playwright-report
test-results

I Dockerfile devono usare cache mount per install dipendenze, ad esempio:

RUN --mount=type=cache,target=/root/.npm npm ci --ignore-scripts
RUN --mount=type=cache,id=pnpm-store,target=/root/.local/share/pnpm/store pnpm install --frozen-lockfile

Questa policy riduce build context e cache ricostruita inutilmente. Non sostituisce l'ottimizzazione di asset realmente necessari all'app.

Note specifiche

Alessandro Zucchini

Risolto il 2026-06-19 un errore SSL required su Prisma. La DATABASE_URL e POSTGRES_PRISMA_URL ora puntano a DigitalOcean PostgreSQL con sslmode=require.

Wash Dog Ferrara

Deployato come due servizi distinti:

• admin sulla porta 3000;
• staff sulla porta 3001.

Ha endpoint cron in pausa in attesa di infrastruttura proprietaria.

Sonja Trekking / Tulpa Studio

Anche queste app hanno endpoint cron. Sono in pausa come per Wash Dog Ferrara.

Tulpa Studio resta il repo con build context piu' pesante per asset reali nel repository. La policy .dockerignore evita cache e file locali, ma l'ottimizzazione ulteriore richiede revisione asset/app-specific.

Problemi aperti comuni

• DNS staging *.vps.obelica.com allineato a 129.212.141.97;
• certificati trusted ottenuti su staging;
• smoke test staging globale verde;
• alcune app hanno audit warning npm o warning framework durante build;
• alcune app hanno asset/repo grandi che non vanno esclusi automaticamente senza revisione applicativa;
• cron job non schedulati;
• verifica feature specifiche app per app prima dello switch produzione.