Team e accesso
Quattro ruoli cliente, sub-account che rispecchiano l'effettiva struttura della Sua azienda, chiavi API per organizzazione, single sign-on e un registro di controllo per ogni azione privilegiata. Lo stesso modello di accesso è attivo su dashboard, API, CLI, Terraform e sul nostro server MCP. Disponibilità: il provider Terraform è in fase di sviluppo attivo e non è ancora disponibile. Tutto il resto descritto qui è già attivo oggi.
L'accesso non è un semplice interruttore di accensione. Ogni organizzazione cliente viene fornita con quattro ruoli, ciascuno dei quali è un pacchetto fisso di permessi granulari module.action, in modo che un contatto finanziario non tocchi mai un server e uno sviluppatore non veda mai una fattura.
Controllo completo dell'organizzazione e dei relativi sub-account: creazione di organizzazioni figlio, invito e rimozione di membri, modifica dei ruoli, gestione delle chiavi API, provisioning, riavvio, sospensione ed eliminazione di siti, gestione di fatture e metodi di pagamento e lettura del registro di audit. Due aspetti esulano deliberatamente da questo ambito: la chiusura di un'organizzazione e l'emissione di rimborsi sono azioni riservate allo staff, non a un ruolo cliente.
Tutto ciò che riguarda le finanze e nient'altro: fatture, abbonamenti, metodi di pagamento e il catalogo dei piani, oltre a una panoramica dell'organizzazione e del relativo elenco dei membri. Nessun accesso al sito: un contatto finanziario o un contabile esterno non può riavviare, sospendere o eliminare alcunché.
Lavora sui siti senza toccare il denaro: visualizza e crea siti, riavvia i servizi, pulisci la cache, gestisci le chiavi API e apri o rispondi ai ticket di supporto. Nessuna vista di fatturazione, nessun gestione dei membri, nessuna sospensione e nessuna eliminazione: le azioni distruttive e commerciali restano di competenza del proprietario.
Una vista completa senza la possibilità di modificare nulla: membri, siti, fatturazione, piani, ticket, stato delle traduzioni e registro di controllo. Il ruolo giusto per un cliente stakeholder, un revisore interno o un nuovo assunto che deve ancora ambientarsi.
La gestione dei tenant è un albero, non un elenco piatto. Un'organizzazione rivenditrice si trova sopra le organizzazioni dei propri clienti, e i siti si trovano sotto di esse. Un membro del team è un'associazione — un utente, un'organizzazione, un ruolo — quindi la stessa primitiva alimenta un team di due persone, un'agenzia che gestisce cento account di clienti e un rivenditore che gestisce sub-account con il proprio marchio.
I ruoli vengono assegnati per singola organizzazione e anche l'applicazione delle restrizioni avviene su base organizzativa. Un ruolo in un'organizzazione non concede alcun accesso in un'altra organizzazione distinta e non correlata: un fornitore esterno può essere Sviluppatore su un account cliente e Sola lettura su un secondo, effettuando l'accesso con le stesse credenziali. L'accesso si propaga tuttavia verso il basso nella propria gerarchia: un ruolo in un'organizzazione padre si applica alle organizzazioni annidate al di sotto di essa, che è il modo in cui i rivenditori e le agenzie gestiscono i propri clienti.
L'isolamento è applicato a livello di database, non solo nel codice dell'applicazione. La sicurezza a livello di riga di Postgres limita ogni query del tenant al sottoalbero del chiamante e qualsiasi elemento esterno a quel sottoalbero restituisce un errore di non trovato anziché un errore di autorizzazione, in modo che la piattaforma non confermi mai nemmeno l'esistenza dell'organizzazione o del sito di un altro tenant.
I ruoli non sono una comodità limitata alla dashboard. Qualsiasi modalità di accesso alla piattaforma fa capo alle stesse chiavi di autorizzazione, quindi non esiste alcuna porta di servizio che aggiri le vostre regole di accesso.
Siti, fatturazione, ticket, avvisi, notifiche, chiavi API e gestione del team in un'unica shell. L'interfaccia mostra ciò che il ruolo del membro autenticato consente, in modo che agli utenti non vengano mostrati controlli che non possono utilizzare.
L'API pubblicata è la stessa API del motore utilizzata dalla dashboard. Le chiavi API vengono emesse per singola organizzazione con ambiti granulari associati ai permessi RBAC, e le modalità separate di sandbox e live consentono di testare le integrazioni senza toccare la fatturazione o il provisioning reali.
Gestisci siti, domini, DNS, caselle di posta e piani come infrastruttura come codice ed esegui terraform apply per effettuare il provisioning dell'hosting, regolato dagli stessi ambiti di qualsiasi altra risorsa.
Collega Claude Code, Cursor, ChatGPT, Claude Desktop o qualsiasi strumento compatibile con MCP. I token sono limitati a un'organizzazione e ai suoi permessi RBAC, revocabili per singolo strumento, con conferma per le azioni distruttive, limiti di spesa e un audit trail completo.
Viene memorizzato solo un hash di ciascuna chiave API, mai la chiave in chiaro. Le chiavi dispongono di un nome e di un prefisso visibile per consentirti di distinguerle, registrare quando sono state usate l'ultima volta e revocarle singolarmente senza interrompere le altre.
L'identità si basa su Keycloak, quindi l'autenticazione è basata su OIDC e SAML nativi anziché su un modulo di accesso personalizzato aggiunto a un pannello di hosting.
Ogni azione privilegiata scrive un record di audit di sola aggiunta: chi l'ha eseguita, cosa ha fatto, su cosa l'ha fatta, le prove a supporto e l'indirizzo IP di origine. Il registro è di sola aggiunta — gli eventi vengono aggiunti, non modificati sul posto — e in produzione è partizionato per tempo in modo da rimanere veloce man mano che cresce.
Leggere quel registro è di per sé un permesso. I proprietari e i membri di sola lettura lo possiedono, quindi la persona responsabile dell'account e quella che lo verifica possono entrambe vedere l'intera cronologia senza bisogno di privilegi elevati per farlo.
Intorno a questi si trovano i controlli richiesti dai team più grandi: criteri di sessione, elenchi consentiti di IP facoltativi per organizzazione e autenticazione avanzata per le azioni sensibili, in modo che una sessione attiva da sola non basti per compiere operazioni rilevanti.
Il catalogo dei permessi è costituito da dati e non da logica hardcoded: ecco perché può essere esteso senza dover ricablare la piattaforma.
Il proprietario ha il controllo completo dell'organizzazione e dei relativi sub-account, inclusi membri, chiavi API, siti e metodi di pagamento. Il responsabile della fatturazione visualizza fatture, abbonamenti, metodi di pagamento e piani, senza accesso ai siti. Lo sviluppatore gestisce siti e chiavi API e gestisce i ticket, senza controllo su fatturazione o membri. Il ruolo di sola lettura può visualizzare membri, siti, fatturazione, piani, ticket e registro di audit senza modificare nulla.
Non è ancora disponibile come impostazione per singolo sito: limitare un unico abbonamento a siti specifici è un miglioramento pianificato. Oggi puoi ottenere la stessa separazione con l'albero dei tenant: inserisci quei siti in un'organizzazione figlia e assegna alla persona un ruolo lì. Poiché i ruoli vengono concessi per organizzazione, tale accesso non si estende a nessun altro elemento del tuo account.
No — le chiavi API vengono emesse per organizzazione, con ambiti granulari legati agli stessi permessi RBAC e modalità sandbox e live separate. Usale come credenziali di servizio per integrazioni, CI o Terraform, e usa le membership per le persone. Viene memorizzato solo un hash di ciascuna chiave, ogni chiave registra quando è stata usata l'ultima volta e qualsiasi chiave può essere revocata singolarmente.
Il ruolo di Sviluppatore include la visualizzazione e il provisioning dei siti, il riavvio dei servizi, lo svuotamento della cache, la gestione delle chiavi API e la gestione dei ticket. Non conferisce diritti di pubblicazione su un sito live, quindi se desideri che qualcuno possa promuovere modifiche, tale accesso deve essere assegnato a un proprietario. I ruoli sono definiti per organizzazione, quindi puoi averne uno diverso su un account differente.
Sì. L'identità è gestita tramite Keycloak con OIDC e SAML, quindi il Single Sign-On SAML è disponibile per i clienti enterprise e agency, insieme all'accesso tramite magic-link, email e password, social provider, passkey e autenticazione a due fattori TOTP, applicata tramite policy. Una singola sessione copre la dashboard, il sito pubblico, la knowledge base e i ticket di supporto.
Ogni azione privilegiata viene registrata in un registro di audit a sola scrittura che memorizza l'autore, l'azione, l'obiettivo, le prove a supporto e l'indirizzo IP. La sua lettura costituisce un permesso a sé stante, detenuto sia dal ruolo Proprietario che da quello di sola lettura, consentendo così a un proprietario dell'account e a un revisore di esaminare la stessa cronologia.
I piani hanno un prezzo basato sulla capacità di hosting anziché sul numero di persone. Sulla linea Footprint-Free, ad esempio, tutti i 42 livelli condividono esattamente lo stesso set di diritti e differiscono solo per il numero di siti che consentono. I prezzi vengono sempre elaborati dal catalogo live, nella vostra valuta, quindi ciò che vedete nella pagina dei prezzi è ciò che viene effettivamente addebitato.
Sì. La prova di Footprint-Free dura 14 giorni, non richiede carta di credito e copre fino a 5 siti, così puoi configurare la tua organizzazione, invitare il tuo team e testare i ruoli su attività reali prima di pagare qualsiasi importo. I piani a pagamento sono coperti da una garanzia di rimborso di 30 giorni.
Avvia una prova gratuita di 14 giorni senza carta di credito sulla linea Footprint-Free, invita il tuo team e verifica il funzionamento dei ruoli su siti reali prima di effettuare qualsiasi pagamento.
Inizia gratis