> ## Documentation Index
> Fetch the complete documentation index at: https://supastack.dev/llms.txt
> Use this file to discover all available pages before exploring further.
> For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt

# Crea gli account di rilascio desktop

Credenziali di firma e notarizzazione Apple, opzioni di firma del codice su Windows e il backend ospitato di cui una shell pubblicata ha bisogno.

## Quando servono

Il lavoro desktop in locale non richiede nulla di questa pagina — `corepack pnpm --filter @supastack/desktop dev` esegue la shell, e `tauri build` produce installer non firmati che funzionano benissimo sulla tua macchina.

Questi account contano solo prima di una release pubblica: la firma del codice e la notarizzazione di Apple sono ciò che elimina gli avvisi di sicurezza che i computer altrui mostrano per un'app sconosciuta. Creali quando una release si avvicina, non il primo giorno.

[Configurare Amazon SES con SDK AWS o IAM SMTP](https://supastack.dev/it/docs/web/aws-ses.md)


## Apple: certificato + chiave di notarizzazione

1. Iscriviti al [programma Apple Developer](https://developer.apple.com) — 99 $ all'anno. La stessa iscrizione che invia app iOS copre la firma di macOS; non paghi due volte.

2. Crea un certificato Developer ID Application su un Mac: Xcode → Settings → Accounts → il tuo account → Manage Certificates → + → Developer ID Application (il flusso certificate-assistant di Accesso Portachiavi è l'alternativa).

3. La notarizzazione — il controllo lato server di Apple di cui Gatekeeper si fida — usa una chiave API di App Store Connect: apri [appstoreconnect.apple.com](https://appstoreconnect.apple.com) → Users and Access → Integrations → App Store Connect API → genera una chiave, scarica subito il file `.p8` (viene offerto una sola volta) e annota il Key ID e l'Issuer ID.

Queste credenziali alimentano i nomi di ambiente `APPLE_*` documentati in Code signing — il certificato, la sua password, l'identità di firma e la coppia chiave API/emittente. Conserva ciascuna in un archivio dei segreti, mai nel repo.

[Collegare le credenziali alla build](https://supastack.dev/it/docs/desktop/signing.md)


## Firma del codice su Windows

Esistono due opzioni: acquistare un certificato di firma del codice OV o EV da un'autorità di certificazione — EV rimuove gli avvisi SmartScreen più in fretta mentre OV costruisce reputazione nel tempo — oppure usare il servizio Azure Trusted Signing di Microsoft con un account Azure, la via in abbonamento più recente.

Gli installer non firmati si installano ed eseguono comunque; attivano avvisi SmartScreen per chiunque li scarichi. Accettabile per test privati, inaccettabile per una release pubblica.

L'impronta del certificato o un comando `signtool` personalizzato va nella configurazione del bundle Windows — i dettagli sono in Code signing; questa pagina copre solo l'account.

[Configurare la firma su Windows](https://supastack.dev/it/docs/desktop/signing.md)


## Un URL di backend pubblico

La shell desktop è una webview, non un'app autonoma: una build di release deve caricare un backend HTTPS pubblico, che fornisci incorporando `SUPASTACK_APP_URL` nella build. Una shell che punta a `localhost` è uno strumento locale, non un prodotto.

Distribuisci prima l'app web — il percorso Google Cloud produce l'URL HTTPS, e la checklist di distribuzione è il riferimento più breve. Imposta `SUPASTACK_APP_URL` su di esso quando costruisci la release.

[Distribuire il backend su Google Cloud](https://supastack.dev/it/docs/web/deploy-google-cloud.md)

[Checklist di deployment](https://supastack.dev/it/docs/web/deployment.md)


## Un endpoint di aggiornamento

L'updater di Tauri interroga un manifesto HTTPS `latest.json` per sapere le nuove versioni. Qualsiasi host statico va bene — una release di GitHub Releases o un file in un bucket S3/R2 — quindi un account GitHub esistente basta per iniziare; non serve un servizio separato.

È solo preparazione a livello di account: il cablaggio dell'updater vero e proprio riguarda il lavoro Bundle e release al momento dell'uscita, non qualcosa da configurare ora.


## Cosa significa «finito»

Controlla ogni voce prima del lavoro di release: Apple mostra un'iscrizione Developer Program attiva, un certificato Developer ID Application è nel Portachiavi, e la `.p8` di App Store Connect è salvata con il suo Key ID e l'Issuer ID annotati. Su Windows è stato scelto un percorso di certificato — acquisto da una CA o Trusted Signing — oppure hai deciso esplicitamente di distribuire senza firma per ora.

Il controllo del backend: esiste una distribuzione HTTPS pubblica e `SUPASTACK_APP_URL` per le build di release punta a essa. Il controllo degli aggiornamenti: è stato scelto un host per `latest.json` — GitHub Releases o un bucket.

Poi prosegui nell'ordine:

[Bundle e rilascio](https://supastack.dev/it/docs/desktop/release.md)

[Firma del codice](https://supastack.dev/it/docs/desktop/signing.md)

[Distribuire il backend condiviso](https://supastack.dev/it/docs/web/deployment.md)


Per continuare la configurazione, leggi [Bundle e rilascio](https://supastack.dev/it/docs/desktop/release.md).


## Successivo

[Bundle e rilascio](https://supastack.dev/it/docs/desktop/release.md)