Vai al contenuto
Crea un account gratuito
Crea un account gratuito
Self-hostingServer disponibile su richiesta

Esegui il server dove lavori già

Il server Crunu è cieco per progettazione. Su app.crunu.com o su un’infrastruttura che controlli tu, conserva testo cifrato, chiavi pubbliche e record firmati, e non ha nessuna chiave in grado di decifrare un solo valore.

Crea un account gratuitoLeggi la guida al self-hosting
Esempio. Kiteline è un’azienda fittizia.

Prima dell’installazione

  • 1Node.js 24 e il codice del serverGli strumenti per l’operatore server-init, doctor e crunu-server girano su Node.js. Il server non è un download pubblico: scrivi a support@crunu.com per riceverlo.
  • 2Un indirizzo che terraiLe firme di accesso, i link di condivisione, le passkey e gli agenti sono legati al dominio del server, quindi non può cambiare in seguito.
  • 3Un posto sicuro per .envVa bene un password manager. Il file contiene SERVER_KEY, il segreto principale del server.

Una volta per server

Installa

Cinque passaggi ti portano da una macchina o un account cloud vuoti a un server funzionante con il suo primo proprietario.

  1. 1Decidi chi gestisce il server

    La cifratura avviene nel browser e nell’agente crunu, mai sul server. Quindi scegliere tra app.crunu.com e un tuo server significa scegliere chi lo gestisce e chi vede i suoi metadati. In entrambi i casi, nessuno dal lato server può leggere i tuoi valori.

    • app.crunu.com: Crunu gestisce il server su Cloudflare Workers con un database D1, gratis durante l’accesso anticipato
    • Un tuo server: lo gestisci tu, paghi il provider della tua piattaforma e solo tu vedi i suoi metadati
    • Per metadati si intendono i nomi di organizzazioni, progetti, ambienti e macchine, gli indirizzi email, il registro di audit e la dimensione e l’ora delle versioni
    Esempio. Kiteline è un’azienda fittizia.

  2. 2Genera le impostazioni del server

    server-init scrive un file .env con una nuova SERVER_KEY, un BOOTSTRAP_TOKEN monouso per il primo proprietario e un CRON_SECRET. Solo il tuo utente può leggere il file.

    • Salvane subito una copia nel tuo password manager
    • Perdere SERVER_KEY disconnette tutti e rende inutilizzabili i link di condivisione. I dati degli ambienti restano intatti

  3. 3Scegli una delle cinque piattaforme

    Ogni piattaforma esegue lo stesso server con lo stesso schema di database, e l’app web è integrata nel server. Ogni script di deploy controlla .env con lo stesso codice che il server usa all’avvio, quindi un’impostazione sbagliata ferma il deploy con un messaggio chiaro.

    • Docker su un tuo server: Caddy emette i certificati TLS, e Cloudflare Tunnel funziona quando non vuoi porte aperte
    • Cloudflare Workers: Free va bene per una prova, ma un team ha bisogno di Workers Paid, perché Free concede a ogni richiesta 10 ms di tempo CPU
    • Vercel: le anteprime hanno un proprio database e una propria chiave del server, e sul piano Hobby la pulizia viene eseguita al massimo una volta al giorno
    • AWS App Runner solo negli account AWS che lo usano già: AWS lo ha chiuso ai nuovi clienti, e Crunu non ha uno script per Amazon ECS Express Mode
    Esempio. Kiteline è un’azienda fittizia.

  4. 4Esegui il deploy con lo script della piattaforma

    Un solo comando per piattaforma compila il server ed esegue il deploy. I segreti raggiungono la piattaforma tramite stdin o un file che solo tu puoi leggere, mai tramite argomenti dei comandi o il loro output. Il server applica da solo le migrazioni del database all’avvio.

    • Lo stesso script installa la prima versione e ogni aggiornamento
    • Su Cloudflare, codice e segreti vengono pubblicati come un’unica versione, quindi un deploy non riuscito non cambia nulla

  5. 5Crea il primo proprietario

    Apri l’indirizzo del server e inserisci la chiave di bootstrap presa da .env. Le chiavi del tuo account e dell’organizzazione vengono create nel browser, e la chiave di bootstrap smette di funzionare dopo questo unico utilizzo. Poi salva il tuo Emergency Kit, crea un codice di recupero e attiva un secondo fattore.

    • Senza l’Emergency Kit e la tua password, un nuovo dispositivo non può accedere
    • Tutti gli altri entrano su invito

Ogni giorno

Gestisci

Una volta avviato, tre abitudini mantengono il server in salute: un controllo dopo ogni deploy, il monitoraggio e un backup giornaliero.

  1. 6Controlla il deployment con doctor

    doctor controlla dall’esterno un server in funzione: stato di salute, TLS e scadenza del certificato, intestazioni di sicurezza, compressione delle risposte dell’API, orologio del server, release dell’agente, migrazioni, pulizia e indirizzo del client dietro i proxy.

    • Un risultato complessivo e un codice di uscita, quindi si integra in cron e nella CI
    • --json fornisce un output leggibile dalle macchine

  2. 7Tieni d’occhio salute, metriche e avvisi

    GET /v2/health funziona con i servizi di controllo della disponibilità come UptimeRobot o Better Stack. GET /v2/status con un token operatore restituisce le metriche in JSON o in formato Prometheus, senza valori e senza indirizzi email. Gli avvisi raggiungono il tuo team tramite un webhook firmato o via email.

    • Slack, Microsoft Teams e PagerDuty si collegano tramite i loro webhook in entrata
    • Su Cloud Run e App Runner la pulizia viene eseguita solo quando c’è traffico, quindi gli avvisi basati sullo stato possono arrivare in ritardo

  3. 8Esegui il backup su qualsiasi storage

    crunu-server export scrive l’intero database in un unico archivio. Non contiene valori in chiaro, quindi puoi conservarlo presso qualsiasi fornitore. Tieni il file .env separato dall’archivio, nel tuo password manager.

    • Esporta ogni giorno e conserva 30 giorni. Il server non ha uno scheduler integrato, e la guida ai backup fornisce una riga cron pronta per Docker
    • Verifica una copia ogni mese o, meglio ancora, ripristinala in un database di prova
    • Un ripristino annulla tutto ciò che è successo dopo la copia, e i dispositivi che hanno visto dati più recenti rifiutano lo stato precedente finché non li azzeri

Quando serve

Modifica

Per spostare il server, ruotare la sua chiave e aggiornarlo si usano gli script di deploy e crunu-server che hai già.

  1. 9Passa a un’altra piattaforma con un solo archivio

    Esporta il database, verifica l’archivio, importalo in un database vuoto sulla nuova piattaforma ed esegui lì il deploy con lo stesso .env, poi cambia il DNS. Ognuna delle sei configurazioni può passare a qualsiasi altra, in entrambe le direzioni.

    • Mantieni la stessa SERVER_KEY e lo stesso indirizzo. Cambia solo il record DNS
    • Le macchine continuano a funzionare con le variabili che hanno già per la durata del loro lease, fino a 24 ore
    • Tieni la vecchia piattaforma per una settimana. Tornare indietro è una modifica del DNS
    Esempio. Kiteline è un’azienda fittizia.

  2. 10Ruota la chiave del server senza disconnettere nessuno

    Durante una rotazione la chiave precedente continua a funzionare, i token vengono ricalcolati con la nuova chiave man mano che vengono usati, e rotate-key cifra di nuovo i segreti TOTP e i canali degli avvisi. Le persone restano connesse e i link di condivisione continuano ad aprirsi. I dati degli ambienti non vengono mai cifrati con questa chiave.

    • Quattro passaggi: new-server-key, deploy, rotate-key, drop-previous-key
    • Ruotala quando .env potrebbe essere stato visto, dopo uno spostamento o una volta all’anno

  3. 11Aggiorna senza un passaggio di migrazione separato

    Un aggiornamento usa lo stesso script di deploy della prima installazione, e il server applica le migrazioni all’avvio. Le migrazioni aggiungono soltanto, e quelle già rilasciate sono protette da checksum, quindi puoi riportare indietro il codice senza riportare indietro il database.

    • Le release web sono firmate, e il server fornisce la firma, così un sito pubblicato può essere confrontato con essa
    • Non è possibile tornare a una versione precedente alla 6.0

Guide per chi gestisce il server

Domande sul self-hosting

Cosa chiede chi gestisce il server prima di eseguirne uno proprio.

Un’altra domanda? Scrivi a support@crunu.com.

app.crunu.com usa lo stesso software che posso ospitare io?

Sì. app.crunu.com esegue lo stesso server Crunu, distribuito su Cloudflare Workers con un database D1.

Chi gestisce app.crunu.com può leggere i miei segreti?

No. Il server conserva testo cifrato e non ha alcuna chiave per decifrarlo. In quanto gestore, Crunu vede i metadati: i nomi di organizzazioni, progetti, ambienti e macchine, gli indirizzi email, il registro di audit e la dimensione e l’ora di ogni versione. Un rischio vale per ogni vault basato sul web: un server compromesso potrebbe fornire un’app web modificata che vede la tua password e la tua Secret Key quando accedi. Le release firmate e una policy di sicurezza dei contenuti rigorosa riducono questo rischio, e la pagina delle limitazioni spiega il resto.

Posso passare in seguito da app.crunu.com a un mio server?

Non in un solo passaggio. L’archivio che sposta un server tra piattaforme si ricava dall’intero database del server, e su app.crunu.com solo il gestore vi ha accesso. In qualsiasi momento puoi esportare come file .env ogni ambiente che puoi leggere o scaricare una copia offline, e poi aggiungere quei file al tuo server. Cronologia, impostazioni di accesso e registro di audit non si trasferiscono in questo modo.

AWS è supportato?

In parte. Lo script di Crunu esegue il deploy su AWS App Runner, ma AWS ha chiuso App Runner ai nuovi clienti, quindi funziona solo negli account che lo usano già. Crunu non ha uno script per Amazon ECS Express Mode, il servizio che AWS consiglia al suo posto. Con un nuovo account AWS, scegli Cloud Run, Vercel o un tuo server.

Cosa succede a macchine e CI durante uno spostamento?

Le macchine continuano a funzionare con le variabili che hanno già, per la durata del loro lease, fino a 24 ore. Chiedi al team di non modificare gli ambienti e di non invitare persone per 15–30 minuti mentre esegui il passaggio: ciò che viene scritto sul vecchio server dopo l’esportazione non arriverà a quello nuovo.

Posso eseguire più istanze del server per l’alta disponibilità?

Su Postgres, più istanze possono condividere un unico database: le scritture nel registro di audit vengono serializzate da un lock del database. Non esiste una guida per un cluster di failover, quindi pianificalo come una tua configurazione.

Gli strumenti per l’operatore hanno un’interfaccia in inglese?

Sì. server-init, doctor e crunu-server stampano i loro messaggi in inglese, oppure in russo se CRUNU_LANG o il locale di sistema è impostato sul russo.

Come ottengo il server per il self-hosting?

Il server non è pubblicato come download pubblico. Scrivi a support@crunu.com e indica quale piattaforma intendi usare.

Prova prima Crunu sul servizio ospitato

Gratis durante l’accesso anticipato. La tua password e la tua Secret Key vengono create nel browser e non raggiungono mai il server.

Crea un account gratuitoChiedi informazioni sul self-hosting