Skip to main content

Gestione della Configurazione

Prima volta che installi? Segui la guida all’installazione di Docker Compose per far funzionare Twenty, quindi torna qui per la configurazione.
Twenty offre due modalità di configurazione per soddisfare diverse esigenze di distribuzione: Accesso al pannello di amministrazione: Solo gli utenti con privilegi di amministrazione (canAccessFullAdminPanel: true) possono accedere all’interfaccia di configurazione.

1. Configurazione del Pannello di Amministrazione (Predefinito)

La maggior parte della configurazione avviene tramite l’interfaccia utente dopo l’installazione:
  1. Accedi alla tua istanza Twenty (solitamente http://localhost:3000)
  2. Vai a Impostazioni / Pannello di Amministrazione / Variabili di Configurazione
  3. Configura integrazioni, email, storage e altro
  4. Le modifiche hanno effetto immediato (entro 15 secondi per distribuzioni multi-container)
Distribuzioni Multi-Container: Quando si utilizza la configurazione del database (IS_CONFIG_VARIABLES_IN_DB_ENABLED=true), sia i container server che worker leggono dallo stesso database. Le modifiche al pannello di amministrazione influiscono su entrambi automaticamente, eliminando la necessità di duplicare le variabili di ambiente tra i container (eccetto per le variabili infrastrutturali).
Cosa puoi configurare tramite il pannello di amministrazione:
  • Autenticazione - Google/Microsoft OAuth, impostazioni della password
  • Email - Impostazioni SMTP, modelli, verifica
  • Storage - Configurazione S3, percorsi storage locale
  • Integrazioni - Gmail, Google Calendar, servizi Microsoft
  • Workflow e limitazione della frequenza - Limiti di esecuzione, throttling delle API
  • E molto altro ancora…
Variabili di Configurazione del Pannello di Amministrazione
Ogni variabile è documentata con descrizioni nel tuo pannello di amministrazione in Impostazioni → Pannello di Amministrazione → Variabili di Configurazione. Alcune impostazioni infrastrutturali come connessioni al database (PG_DATABASE_URL), URL del server (SERVER_URL) e segreti (ENCRYPTION_KEY, FALLBACK_ENCRYPTION_KEY) possono essere configurate solo tramite file .env.Riferimento tecnico completo →

Chiavi di crittografia

Twenty utilizza due chiavi di crittografia disponibili solo tramite variabili d’ambiente: Per garantire la retrocompatibilità, se ENCRYPTION_KEY non è impostata, Twenty torna a utilizzare APP_SECRET per la crittografia a riposo, in modo da rispecchiare il comportamento legacy delle distribuzioni meno recenti. Le nuove installazioni dovrebbero sempre impostare una ENCRYPTION_KEY dedicata. Genera i valori con openssl rand -base64 32 e conservali in un luogo sicuro (un secrets manager, configurazioni sigillate, ecc.). Perdere ENCRYPTION_KEY significa perdere l’accesso a ogni segreto memorizzato nel database. Per ruotare ENCRYPTION_KEY senza tempi di inattività, consulta la guida alla rotazione delle chiavi.

2. Configurazione Solo-Ambiente

Tutta la configurazione gestita tramite file .env:
  1. Imposta IS_CONFIG_VARIABLES_IN_DB_ENABLED=false nel tuo file .env
  2. Aggiungi tutte le variabili di configurazione nel tuo file .env
  3. Riavvia i container per applicare le modifiche
  4. Il pannello di amministrazione mostrerà i valori attuali ma non potrà modificarli

Modalità multi-workspace

Per impostazione predefinita, Twenty viene eseguito in modalità a workspace singolo — ideale per la maggior parte delle distribuzioni self-hosted in cui è necessaria un’istanza di CRM per la tua organizzazione.

Modalità a workspace singolo (predefinita)

  • Un workspace per istanza di Twenty
  • Il primo utente diventa automaticamente amministratore con privilegi completi (canImpersonate e canAccessFullAdminPanel)
  • Le nuove registrazioni sono disabilitate dopo la creazione del primo workspace
  • Struttura URL semplice: https://your-domain.com

Abilitare la modalità multi-workspace

Abilita la modalità multi-workspace per distribuzioni in stile SaaS in cui più team indipendenti necessitano dei propri workspace sulla stessa istanza di Twenty. Differenze principali rispetto alla modalità a workspace singolo:
  • È possibile creare più workspace sulla stessa istanza
  • Ogni workspace ottiene il proprio sottodominio (ad es., sales.your-domain.com, marketing.your-domain.com)
  • Gli utenti si registrano e accedono su {DEFAULT_SUBDOMAIN}.your-domain.com (ad es., app.your-domain.com)
  • Nessun privilegio amministrativo automatico — il primo utente in ogni workspace è un utente normale
  • Le impostazioni specifiche del workspace, come sottodominio e dominio personalizzato, diventano disponibili nelle impostazioni del workspace
Impostazione solo per l’ambiente: IS_MULTIWORKSPACE_ENABLED può essere configurata solo tramite il file .env e richiede un riavvio. Non può essere modificata tramite il pannello di amministrazione.

Configurazione DNS per la modalità multi-workspace

Quando si utilizza la modalità multi-workspace, configura il DNS con un record wildcard per consentire la creazione dinamica dei sottodomini:
Ciò abilita l’instradamento automatico dei sottodomini per i nuovi workspace senza configurazione DNS manuale.

Limitare la creazione di workspace

In modalità multi-workspace, potresti voler limitare chi può creare nuovi workspace:
Quando è abilitata, solo gli utenti con canAccessFullAdminPanel possono creare workspace aggiuntivi. Gli utenti possono comunque creare il loro primo workspace durante la registrazione iniziale.

Integrazione Gmail & Google Calendar

Crea Progetto nel Google Cloud

  1. Vai a Google Cloud Console
  2. Crea un nuovo progetto o seleziona uno esistente
  3. Abilita queste API:

Configura OAuth

  1. Vai a Credenziali
  2. Crea ID client OAuth 2.0
  3. Aggiungi questi URI di reindirizzamento:
    • https://{your-domain}/auth/google/redirect (per SSO)
    • https://{your-domain}/auth/google-apis/get-access-token (per integrazioni)

Configura in Twenty

  1. Vai a Impostazioni → Pannello di Amministrazione → Variabili di Configurazione
  2. Trova la sezione Google Auth
  3. Imposta queste variabili:
    • MESSAGING_PROVIDER_GMAIL_ENABLED=true
    • CALENDAR_PROVIDER_GOOGLE_ENABLED=true
    • AUTH_GOOGLE_CLIENT_ID={client-id}
    • AUTH_GOOGLE_CLIENT_SECRET={client-secret}
    • AUTH_GOOGLE_CALLBACK_URL=https://{your-domain}/auth/google/redirect
    • AUTH_GOOGLE_APIS_CALLBACK_URL=https://{your-domain}/auth/google-apis/get-access-token
Modalità solo ambiente: Se imposti IS_CONFIG_VARIABLES_IN_DB_ENABLED=false, aggiungi queste variabili al tuo file .env invece.
Scope richiesti (configurati automaticamente): Vedi il codice sorgente pertinente
  • https://www.googleapis.com/auth/calendar.events
  • https://www.googleapis.com/auth/gmail.readonly
  • https://www.googleapis.com/auth/profile.emails.read

Se la tua app è in modalità di test

Se la tua app è in modalità di test, dovrai aggiungere utenti di prova al tuo progetto. Sotto Schermo di Consenso OAuth, aggiungi i tuoi utenti di prova nella sezione “Utenti di Prova”.

Integrazione Microsoft 365

Gli utenti devono avere una Licenza Microsoft 365 per poter utilizzare l’API Calendario e Messaggi. Non potranno sincronizzare il loro account su Twenty senza una.

Crea un progetto in Microsoft Azure

Avrai bisogno di creare un progetto in Microsoft Azure e ottenere le credenziali.

Abilita API

Nel Microsoft Azure Console abilita le seguenti API in “Permessi”:
  • Microsoft Graph: Mail.ReadWrite
  • Microsoft Graph: Mail.Send
  • Microsoft Graph: Calendars.Read
  • Microsoft Graph: User.Read
  • Microsoft Graph: openid
  • Microsoft Graph: email
  • Microsoft Graph: profile
  • Microsoft Graph: offline_access
“Mail.ReadWrite” e “Mail.Send” sono obbligatori solo se vuoi inviare email utilizzando le nostre azioni di flusso di lavoro. Puoi usare “Mail.Read” invece se vuoi solo ricevere email.
“Calendars.ReadWrite” è obbligatorio se vuoi creare eventi del calendario utilizzando le nostre azioni di flusso di lavoro. Se vuoi solo sincronizzare gli eventi del calendario, usa “Calendars.Read”.

URI di Riindirizzamento Autorizzati

Devi aggiungere i seguenti URI di reindirizzamento al tuo progetto:
  • https://{your-domain}/auth/microsoft/redirect se vuoi usare Microsoft SSO
  • https://{your-domain}/auth/microsoft-apis/get-access-token

Configura in Twenty

  1. Vai a Impostazioni → Pannello di Amministrazione → Variabili di Configurazione
  2. Trova la sezione Microsoft Auth
  3. Imposta queste variabili:
    • MESSAGING_PROVIDER_MICROSOFT_ENABLED=true
    • CALENDAR_PROVIDER_MICROSOFT_ENABLED=true
    • AUTH_MICROSOFT_ENABLED=true
    • AUTH_MICROSOFT_CLIENT_ID={client-id}
    • AUTH_MICROSOFT_CLIENT_SECRET={client-secret}
    • AUTH_MICROSOFT_CALLBACK_URL=https://{your-domain}/auth/microsoft/redirect
    • AUTH_MICROSOFT_APIS_CALLBACK_URL=https://{your-domain}/auth/microsoft-apis/get-access-token
Modalità solo ambiente: Se imposti IS_CONFIG_VARIABLES_IN_DB_ENABLED=false, aggiungi queste variabili al tuo file .env invece.

Configura scope

Vedi il codice sorgente pertinente
  • ‘openid’
  • ‘email’
  • ‘profilo’
  • ‘offline_access’
  • ‘Mail.ReadWrite’
  • ‘Mail.Send’
  • ‘Calendars.Read’

Se la tua app è in modalità di test

Se la tua app è in modalità di test, dovrai aggiungere utenti di prova al tuo progetto. Aggiungi i tuoi utenti di prova nella sezione “Utenti e gruppi”.

Lavori in Background per Calendario & Messaggistica

Dopo aver configurato le integrazioni di Gmail, Google Calendar o Microsoft 365, devi avviare i lavori in background che sincronizzano i dati. Registrare i seguenti lavori ricorrenti nel tuo container worker:

Configurazione Email

  1. Vai a Impostazioni → Pannello di Amministrazione → Variabili di Configurazione
  2. Trova la sezione Email
  3. Configura le impostazioni SMTP:
Avrai bisogno di provvedere una Password per l’App.
  • EMAIL_DRIVER=smtp
  • EMAIL_SMTP_HOST=smtp.gmail.com
  • EMAIL_SMTP_PORT=465
  • EMAIL_SMTP_USER=indirizzo_email_gmail
  • EMAIL_SMTP_PASSWORD=‘password_app_gmail’
Modalità solo ambiente: Se imposti IS_CONFIG_VARIABLES_IN_DB_ENABLED=false, aggiungi queste variabili al tuo file .env invece.

Archiviazione S3

Per impostazione predefinita, Twenty archivia i file caricati nel file system locale. Per le distribuzioni in produzione, usa S3 o un servizio compatibile con S3 (MinIO, DigitalOcean Spaces, ecc.). per garantire che i file persistano tra i riavvii dei container e per poter scalare su più istanze server.
Imposta STORAGE_TYPE=S_3 e configura le variabili STORAGE_S3_* tramite il pannello di amministrazione o .env. Consulta il riferimento a config-variables.ts per l’elenco completo delle variabili S3. Quando si usa S3 con funzionalità che dipendono da CORS (ad esempio i download di file nel browser), assicurati che il tuo bucket consenta l’origine del tuo frontend di Twenty nella sua configurazione CORS.

Funzioni logiche & interprete del codice

Twenty supporta le funzioni logiche per i workflow e l’interprete del codice per l’analisi dei dati con IA. Entrambi eseguono codice fornito dall’utente e richiedono una configurazione esplicita per motivi di sicurezza.

Impostazioni di sicurezza predefinite

In produzione (NODE_ENV=production): Sia le funzioni logiche sia l’interprete del codice hanno come impostazione predefinita Disabilitato. È necessario abilitarli esplicitamente con LOGIC_FUNCTION_TYPE e CODE_INTERPRETER_TYPE se queste funzionalità sono necessarie. In sviluppo (NODE_ENV=development): Entrambi sono impostati su LOCAL per comodità quando vengono eseguiti in locale.
Avviso di sicurezza: Il driver locale (LOGIC_FUNCTION_TYPE=LOCAL o CODE_INTERPRETER_TYPE=LOCAL) esegue il codice direttamente sull’host in un processo Node.js senza sandboxing. Dovrebbe essere utilizzato solo per codice attendibile in fase di sviluppo. Per le distribuzioni in produzione che gestiscono codice non affidabile, usa LOGIC_FUNCTION_TYPE=LAMBDA o CODE_INTERPRETER_TYPE=E2B (con sandboxing), oppure lasciali disabilitati.

Funzioni logiche - Driver disponibili

Funzioni logiche - Configurazione consigliata

Per lo sviluppo:
Per la produzione (AWS):
Per disabilitare le funzioni logiche:

Interprete del codice - Driver disponibili

Quando si utilizza LOGIC_FUNCTION_TYPE=DISABLED o CODE_INTERPRETER_TYPE=DISABLED, qualsiasi tentativo di esecuzione restituirà un errore. Ciò è utile se si desidera eseguire Twenty senza queste funzionalità.

API e front-end su host separati

Rilevante solo se il back-end non serve il front-end. Le distribuzioni con la stessa origine non richiedono nulla qui. Dichiara tutte le origini del browser che comunicano con l’API, separate da virgole. SERVER_URL e FRONTEND_URL sono già considerate attendibili. Il server registra un avviso quando un browser lo chiama da origine non dichiarata.
Il front-end invia le credenziali su ogni richiesta, e i browser rifiutano una risposta credenziale da un’origine non dichiarata, quindi l’applicazione non riesce a caricare fino a quando hai impostato questo.
Se i due host si trovano su domini registrabili diversi (non solo sottodomini diversi), imposta anche AUTH_COOKIE_SAME_SITE=none, che richiede HTTPS. Con multi-workspace abilitato, non elencare ogni sottodominio workspace qui. Invece, percorsi percorsi API (/graphql, /metadata, /rest, /auth/, /client-config, /file) al back-end su ogni hostname di workspace, quindi ogni workspace rimane la stessa origine — così funziona Twenty Cloud.