Deploy GitHub Actions verso Railway

I repository deployable del workspace usano .github/workflows/railway-deploy.yml per pubblicare su Railway.

Il contratto connector transazionale viene distribuito come package privato @codestormlab/cs-contracts-connectors su GitHub Packages. I consumer devono usare una versione esatta dal registry e non una dipendenza file:.

Il trigger e intenzionalmente ristretto a:

• push verso main
• push verso master
• workflow_dispatch lanciato da main o master

Un merge su main o master genera un push sul branch target, quindi avvia il deploy.

Secret GitHub

Ogni repository deployable usa un Railway Project Token nel secret GitHub RAILWAY_TOKEN:

• RAILWAY_TOKEN: project token per il progetto e l'environment di produzione
• RAILWAY_PROJECT_ID: ID del progetto Railway
• RAILWAY_ENVIRONMENT: ID dell'environment Railway di produzione, obbligatorio

I workflow passano progetto, environment e servizio direttamente a railway up; non eseguono railway link e non usano RAILWAY_API_TOKEN. Il token API è account/workspace scoped e non è adatto ai deploy di un singolo progetto.

Railway ha comunicato che l'incidente del 21 ottobre 2026 ha revocato token API e sessioni CLI. I project token creati prima dell'incidente vanno sostituiti e le pipeline fallite rilanciate. Guida ufficiale di recupero Railway.

Per nomi consigliati dei token, mappatura aggiornata dei repository, ID Railway e link alle impostazioni, consulta la guida workspace per i deploy Railway.

I repository che importano package @platform/* via file:../platform-shared-packages/... devono configurare anche:

• SHARED_PACKAGES_REPOSITORY_TOKEN: token GitHub con lettura su CodeStormLab/cs-products-shared-packages

Il workflow deve fare checkout di platform-shared-packages come directory sibling e includerlo nel build context inviato a Railway. Un deploy Railway nativo dalla sola repository applicativa non risolve queste dipendenze locali.

Per il package privato @codestormlab/cs-contracts-connectors, il workflow configura @codestormlab:registry=https://npm.pkg.github.com e usa GITHUB_TOKEN per i repository consumer appartenenti a CodeStormLab, ai quali il package deve concedere accesso Actions in lettura. sfdc-external, che appartiene a un owner diverso, usa invece CS_NPM_READ_TOKEN con un PAT classic read:packages.

I deploy Railway dei consumer che usano package privati installano e compilano le dipendenze nel runner GitHub, poi inviano a Railway solo gli artefatti runtime gia compilati. Il Dockerfile Railway non deve eseguire un secondo npm ci autenticato.

Repository Coperti

Repository	Servizi Railway
platform-auth-service	auth
platform-ai-service	ai
platform-connectors-service	connectors
platform-payments-service	payments
platform-scraper-service	scraper
platform-agent-service	agent
platform-mcp-service	mcp
platform-status-service	status-api, status-web
platform-wiki	wiki
funnel-ia-engine	api, worker, web
sfdc-external	sfdc-api, sfdc-web
cs-portal	cs-portal-web
cs-chat	cs-products-chat-api, cs-products-chat-web

Procedura Step By Step

1. Recupera Gli ID Railway

Annota:

• <CORE_PROJECT_ID> per i servizi Core
• <FUNNEL_PROJECT_ID> per funnel-ia-engine
• <SFDC_PROJECT_ID> per sfdc-external
• <CS_PORTAL_PROJECT_ID> per cs-portal
• <CS_CHAT_PROJECT_ID> per cs-chat

Usa l'ID dell'environment production in tutti i workflow; non affidarti all'environment predefinito o a un collegamento CLI persistente.

2. Crea I Token

Per un progetto e un environment crea un Project Token, riusabile dai servizi appartenenti alla stessa coppia. I gruppi da ruotare dopo la revoca dei token sono Core, CS Chat, Funnel e SFDC; il token Portal è stato aggiornato il 28 ottobre 2026 e il relativo deploy è riuscito il 29 ottobre, quindi non richiede una nuova rotazione.

• gha-core-prod-202610
• gha-chat-prod-202610
• gha-funnel-prod-202610
• gha-sfdc-prod-202610

Per la pipeline Railway usa solo Project Token e RAILWAY_TOKEN. Il token GitHub SHARED_PACKAGES_REPOSITORY_TOKEN resta necessario ai repository con dipendenze file:../platform-shared-packages/....

3. Configura I Secret Nei Repository

Secret comuni:

• RAILWAY_TOKEN
• RAILWAY_PROJECT_ID
• RAILWAY_ENVIRONMENT, obbligatorio

Secret extra per repository con package condivisi:

• SHARED_PACKAGES_REPOSITORY_TOKEN

Secret extra per repository esterni all organizzazione che installano package privati da GitHub Packages:

• CS_NPM_READ_TOKEN, PAT classic con read:packages, solo se il package non concede accesso al GITHUB_TOKEN del workflow.

4. Associa Il Project Railway Corretto

Usa:

• <CORE_PROJECT_ID> per tutti i repository Core e platform-wiki
• <FUNNEL_PROJECT_ID> per funnel-ia-engine
• <SFDC_PROJECT_ID> per sfdc-external
• <CS_PORTAL_PROJECT_ID> per cs-portal
• <CS_CHAT_PROJECT_ID> per cs-chat

5. Pubblica I Workflow

Per ogni repository:

git add .github/workflows/railway-deploy.yml
git commit -m "ci: add railway deploy workflow"
git push origin main

Per funnel-ia-engine e sfdc-external usa master:

git push origin master

6. Proteggi I Branch

In GitHub, abilita branch protection su main o master:

• pull request obbligatoria prima del merge
• status check obbligatori se configuri anche workflow CI separati
• bypass admin disabilitato se serve una policy rigida

7. Verifica Il Primo Deploy

Apri Actions nel repository, entra nel workflow Deploy to Railway e verifica:

• build completata
• deploy Railway completato
• nuova deployment visibile nel servizio Railway corretto
• healthcheck del servizio in stato healthy

Sincronizzare i secret con le CLI

Railway CLI verifica il progetto e l'environment; GitHub CLI aggiorna i secret. Dal workspace, copia il Project Token appena creato negli appunti ed esegui lo script scripts/sync-railway-github-project-token.sh riportato nella guida workspace. Lo script legge il token da pbpaste, valida il suo scope con l'API Railway e usa gh secret set senza stampare o salvare il valore.

Controlla i nomi e le date, mai i valori, con gh secret list --repo <OWNER/REPOSITORY>. Dopo aver pubblicato il workflow sul branch deploy, controlla l'esito Actions e la nuova deployment Railway; verifica anche lo healthcheck del servizio.