Domande frequenti
Brevi guide pratiche per la configurazione del servizio, l'accesso e le azioni comuni dei clienti.
> Come generare una chiave SSH pubblica nel terminale
Crea una chiave SSH pubblica per l accesso e condividi solo la public key.
Crea una chiave SSH pubblica per l accesso e condividi solo la public key.
Usa solo la chiave pubblica
SSH usa una coppia di chiavi. Incolla nelle impostazioni del servizio solo la chiave pubblica, di solito il file .pub. La chiave privata resta sul tuo dispositivo.
Passaggi nel terminale
- Apri Terminal, Windows Terminal o PowerShell.
- Esegui: ssh-keygen -t ed25519 -C "your-email@example.com".
- Accetta il percorso predefinito o scegli una posizione sicura.
- Mostra la chiave pubblica con: cat ~/.ssh/id_ed25519.pub.
- In Windows PowerShell usa: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
- Copia l intera riga ssh-ed25519 nel campo SSH public key.
Controlla prima di incollare
Non copiare la chiave privata. Se imposti una passphrase, conservala in modo sicuro.
> Creare una chiave SSH con interfaccia grafica in Windows
Procedura grafica Windows con PuTTYgen per creare una chiave SSH.
Procedura grafica Windows con PuTTYgen per creare una chiave SSH.
Serve solo la parte pubblica
PuTTYgen crea una chiave pubblica e una privata. Aggiungi a Cli>_ solo la chiave pubblica e conserva quella privata localmente.
Passaggi in Windows
- Apri PuTTYgen.
- Scegli EdDSA / Ed25519 quando disponibile.
- Usa RSA 4096 solo come alternativa.
- Fai clic su Generate e muovi il mouse finche la chiave viene creata.
- Salva la chiave privata sul tuo computer.
- Copia il testo della chiave pubblica nel campo SSH public key.
Non condividere dati privati
Non inviare file .ppk, chiavi private, passphrase, password o token al supporto o nei moduli.
> Collegare il proprio dominio
Prima del cambio verifica DNS autoritativo, hostname esatto, tipo record, apex o sottodominio e vecchi record in conflitto.
Prima del cambio verifica DNS autoritativo, hostname esatto, tipo record, apex o sottodominio e vecchi record in conflitto.
Conta l’hostname esatto
Stabilisci se colleghi un apex come example.com o un sottodominio come app.example.com. Ogni caso può richiedere record diversi e dipendere dal fornitore DNS o registrar.
Prima della modifica DNS
- Verifica dove si modificano i DNS autoritativi del dominio.
- Rimuovi o modifica A/AAAA, CNAME, ALIAS, ANAME o redirect in conflitto.
- Usa il tipo record consigliato per servizio e hostname.
- Attendi la propagazione DNS prima di testare HTTPS finale.
Rollback sicuro
Non spegnere il vecchio hosting finché il nuovo hostname non risponde correttamente. Per problemi invia dominio, destinazione attesa e risultato DNS pubblico, non accessi al registrar.
> Delegare una zona DNS
A/AAAA puntano a indirizzi, CNAME ad alias, MX alla posta e TXT a verifiche, SPF, DKIM o DMARC.
A/AAAA puntano a indirizzi, CNAME ad alias, MX alla posta e TXT a verifiche, SPF, DKIM o DMARC.
Non mescolare record senza motivo
Ogni tipo DNS ha uno scopo. A e AAAA puntano a IP, CNAME crea alias, MX instrada la posta, TXT contiene verifiche e policy mail, CAA limita le autorità certificatrici.
Quando copi record DNS
- Copia nome, tipo e valore esattamente come indicato.
- Non usare CNAME su hostname con altri record se le regole DNS lo vietano.
- Metti DKIM sotto il selettore del fornitore e DMARC di solito sotto _dmarc.
- Configura CAA con attenzione perché può bloccare il certificato.
Se il DNS non funziona
Invia hostname, tipo record, valore atteso e risultato pubblico. Non mandare login al DNS né screenshot con token API.
> Registrazione account e primo accesso
Crea un account di lavoro, completa la fatturazione e mantieni l’accesso su un’email che il team non perderà.
Crea un account di lavoro, completa la fatturazione e mantieni l’accesso su un’email che il team non perderà.
Un account per ordini e gestione
Usa l’account come punto stabile per ordini, dati di fatturazione, servizi, domini e comunicazioni con il supporto. È preferibile un indirizzo email di lavoro accessibile al team nel tempo.
Prima del primo ordine
- Registrati con un indirizzo email di lavoro.
- Completa la conferma email se richiesta.
- Inserisci i dati di fatturazione prima di un ordine a pagamento.
- Abilita l’autenticazione a due fattori quando disponibile.
Accesso del team senza password in chat
Non inviare la password ai colleghi via chat o email. Se serve accesso a più persone, usate un password manager interno o chiedete una procedura consigliata; il supporto non ha bisogno della password né del token.
> Come funziona il credito prepagato
Il credito mostra saldo, autonomia stimata, costo giornaliero dei servizi attivi e data visibile di eliminazione in caso di sospensione.
Il credito mostra saldo, autonomia stimata, costo giornaliero dei servizi attivi e data visibile di eliminazione in caso di sospensione.
Il credito si consuma durante l’esecuzione
Nei servizi prepagati il saldo diminuisce in base al tempo attivo e alla configurazione scelta. Il costo giornaliero aiuta a stimare quanti giorni restano e quando può comparire una data visibile di eliminazione.
Prevenire la sospensione
- Controlla saldo visibile e autonomia dopo il login.
- Verifica il nuovo costo giornaliero prima di confermare ordini o modifiche.
- Ricarica con margine, non nel giorno dell’esaurimento.
- Se il servizio è sospeso, controlla subito la data possibile di eliminazione.
Controllo del saldo con riferimenti precisi
Per domande sul credito invia numero ordine, nome servizio e periodo da verificare. Non inviare carte, password, chiavi private o estratti completi con dati sensibili.
> Stime mensili, annuali e consumo giornaliero reale
I prezzi mensili e annuali servono per confronto; nei servizi prepagati conta il consumo giornaliero dopo la conferma.
I prezzi mensili e annuali servono per confronto; nei servizi prepagati conta il consumo giornaliero dopo la conferma.
Il confronto non è un calendario di addebito
Usa la stima mensile come confronto su 31 giorni e quella annuale su 372 giorni. Il consumo effettivo dipende dal tempo attivo e dalla configurazione confermata.
Valutare una variazione di prezzo
- Confronta il consumo giornaliero prima e dopo la modifica.
- CPU, RAM, disco o opzioni a pagamento superiori aumentano il consumo.
- Considera la modifica attiva solo dopo conferma, eventuale pagamento e applicazione.
- Conserva conferme ordine e storico credito per la contabilità.
Verifica su un periodo specifico
Il supporto può aiutare meglio con numero ordine, nome servizio e date da controllare. Non inviare dati bancari completi, estratti integrali o screenshot con informazioni personali non necessarie.
> Stato dell’ordine dopo il pagamento
Dopo il pagamento l’ordine può attendere la conferma del fornitore di pagamento; crea duplicati solo se il primo è annullato o scaduto.
Dopo il pagamento l’ordine può attendere la conferma del fornitore di pagamento; crea duplicati solo se il primo è annullato o scaduto.
In attesa non significa per forza errore
Dopo il ritorno dalla pagina di pagamento, l’ordine può attendere la conferma del fornitore di pagamento. Finché non è chiaramente fallito o scaduto, un duplicato può complicare l’abbinamento.
Passi dopo il pagamento
- Torna a Cli>_ quando il pagamento è completato.
- Controlla lo stato dell’ordine e il messaggio visibile.
- Se resta in attesa, attendi la conferma del fornitore di pagamento.
- In caso di problema invia numero ordine e riferimento pagamento se visibile.
Informazioni di pagamento da non inviare
Il supporto non richiede dati della carta, password o ricevute bancarie complete. Servono ordine, orario del pagamento, stato visibile e screenshot mascherato se c’è errore.
> Informazioni che velocizzano la configurazione
Prepara nome servizio, dominio, storage, email di accesso e chiave SSH pubblica; i segreti non vanno nei form.
Prepara nome servizio, dominio, storage, email di accesso e chiave SSH pubblica; i segreti non vanno nei form.
Input precisi evitano ritardi
Nei form d’ordine inserisci valori pubblici o non segreti: nome servizio, dominio, piano DNS, storage, CPU, RAM, email admin o chiave SSH pubblica. Password, chiavi private e token restano fuori dal form.
Preparazione prima del checkout
- Scegli un nome servizio riconoscibile dal team.
- Decidi se usare dominio proprio o hostname temporaneo.
- Prepara la chiave SSH pubblica se richiesta.
- Verifica storage e risorse in base all’applicazione.
Separare valori pubblici e segreti
Se non sai se un dato è segreto, chiedi senza inviarlo. Non mandare chiavi private, password, token, dump database o file di configurazione completi.
> Cambiare CPU, RAM, disco o conservazione dopo l’ordine
Modifica il servizio esistente dal dettaglio; le risorse cambiano prezzo, consumo credito, riavvio e rischio di downtime.
Modifica il servizio esistente dal dettaglio; le risorse cambiano prezzo, consumo credito, riavvio e rischio di downtime.
Modifichi un servizio, non ne crei uno nuovo
Se il servizio è già attivo, cambia le risorse dal suo dettaglio. Un nuovo ordine creerebbe un altro servizio e può modificare prezzo, consumo giornaliero e comportamento solo dopo conferma, eventuale pagamento e applicazione.
Prima di confermare la modifica
- Controlla CPU, RAM, disco, backup e conservazione Offsite Archive attuali.
- Verifica nuovo costo giornaliero e impatto sul credito.
- Leggi eventuali avvisi di riavvio, manutenzione o downtime.
- Esegui un’esportazione dei dati importanti prima di cambi rischiosi.
Quando il cambio non corrisponde alle attese
Invia nome servizio, ora della modifica, stato visibile ed errore. Non inviare chiavi private, password o token; bastano contesto pubblico e screenshot mascherato.
> Cancellazione servizio e data di eliminazione dati
Un servizio già predisposto viene prima sospeso, mostra una data configurabile visibile di eliminazione e poi può essere purgato.
Un servizio già predisposto viene prima sospeso, mostra una data configurabile visibile di eliminazione e poi può essere purgato.
Cancellare non significa sempre eliminare subito
Un servizio già predisposto viene sospeso e mostra una data visibile configurabile entro cui valutare ripristino o esportazione. Ordini in attesa non pagati senza dati in esecuzione possono avere comportamento diverso.
Controlli prima della cancellazione
- Esporta i dati che devi conservare a lungo.
- Leggi data e ora di eliminazione pianificata nel servizio sospeso.
- Non confondere backup e Offsite Archive con il ciclo di eliminazione.
- Se hai dubbi, contatta il supporto prima della data indicata.
Dopo la scadenza il recupero può non riuscire
Dopo la data visibile non considerare i dati disponibili. Per domande invia numero ordine e servizio, non esportazioni database o credenziali.
> Backup e richieste di ripristino
I backup servono al ripristino operativo, non sostituiscono esportazioni proprie; un ripristino può sovrascrivere dati nuovi.
I backup servono al ripristino operativo, non sostituiscono esportazioni proprie; un ripristino può sovrascrivere dati nuovi.
Un backup non è un archivio permanente
La conservazione dei backup dipende dal prodotto e dalle opzioni. Il backup aiuta nel ripristino operativo, ma non sostituisce esportazioni, archivio audit o Offsite Archive.
Preparare una richiesta di ripristino
- Indica nome servizio e numero ordine.
- Descrivi l’orario approssimativo a cui vuoi tornare.
- Specifica se serve tutto il servizio o una parte, se supportato.
- Allega errore visibile o contesto senza password, token o chiavi private.
Conseguenze del ripristino
Se il servizio ha ricevuto dati nuovi, il ripristino può sostituirli con uno stato precedente. Avvisa il team ed esporta ciò che non vuoi perdere prima di confermare.
> A cosa serve Offsite Archive
Offsite Archive conserva copie remote separate dai backup operativi brevi e dal ciclo di vita del servizio.
Offsite Archive conserva copie remote separate dai backup operativi brevi e dal ciclo di vita del servizio.
Archivio remoto fuori dalla normale operatività
Offsite Archive è pensato per copie remote e conservazione più lunga. Non è un disco live per l’applicazione, né sostituisce esportazioni locali o backup operativi brevi.
Quando abilitarlo
- Usalo per dati da conservare fuori dall’operatività normale.
- Scegli i giorni di conservazione secondo compliance, esigenze aziendali o obiettivo di ripristino.
- Ricorda che il prezzo cresce con volume e tempo di conservazione.
- Per grandi dati pianifica l’archivio insieme al processo di esportazione.
Prezzo calcolato su volume e giorni
La base è MB-days: quantità di dati e giorni di conservazione. La tariffa è mostrata come EUR/GB/mese e il risultato viene arrotondato ai centesimi.
> Scegliere CPU, RAM e disco per VPS
Dimensiona la VPS in base ad applicazione, database, cache, log e crescita; OOM o swap indicano più RAM.
Dimensiona la VPS in base ad applicazione, database, cache, log e crescita; OOM o swap indicano più RAM.
Parti dal carico reale
Un sito statico piccolo ha esigenze diverse da database, Java, ricerca o build in container. Considera memoria applicativa, cache, database, log, caricamenti e margine di crescita.
Sintomi di piano troppo piccolo
- Aumenta RAM con OOM, out of memory, process killed o swap continuo.
- Aumenta CPU per carico sostenuto, compressione, build o worker occupati.
- Aumenta disco prima che filesystem, log o database si riempiano.
- Dopo ogni modifica verifica che il limite originale sia sparito.
Dettagli utili per il sizing
Servono nome servizio, tipo applicazione, errore visibile, orario approssimativo e CPU, RAM, disco attuali. Non inviare password, chiavi private o configurazioni interne complete.
> Quando serve una IP pubblica per VPS
Una IP pubblica dedicata aiuta con lista consentita, accesso in ingresso, sorgente in uscita stabile o servizi legati all’indirizzo.
Una IP pubblica dedicata aiuta con lista consentita, accesso in ingresso, sorgente in uscita stabile o servizi legati all’indirizzo.
Capire prima la direzione del traffico
La IP pubblica non è automatica per ogni servizio. Spesso risolve requisiti di partner, fornitori o firewall per lista consentita, sorgente in uscita stabile o accesso in ingresso su una porta specifica.
Domande prima dell’acquisto
- Chiedi se la lista consentita riguarda in ingresso, in uscita o entrambe.
- Usa nomi DNS invece di indirizzi numerici dove possibile.
- Apri solo le porte realmente necessarie all’applicazione.
- Comunica il requisito di lista consentita prima di cambiare accesso in produzione.
Lasciare chiuso ciò che non serve
Una IP pubblica non significa aprire tutte le porte. Progetta l’accesso con servizi minimi e non inviare password, chiavi private o regole firewall interne con valori segreti.
> Checklist prima di collegare un dominio personalizzato
Prima del cambio verifica DNS autoritativo, hostname esatto, tipo record, apex o sottodominio e vecchi record in conflitto.
Prima del cambio verifica DNS autoritativo, hostname esatto, tipo record, apex o sottodominio e vecchi record in conflitto.
Conta l’hostname esatto
Stabilisci se colleghi un apex come example.com o un sottodominio come app.example.com. Ogni caso può richiedere record diversi e dipendere dal fornitore DNS o registrar.
Prima della modifica DNS
- Verifica dove si modificano i DNS autoritativi del dominio.
- Rimuovi o modifica A/AAAA, CNAME, ALIAS, ANAME o redirect in conflitto.
- Usa il tipo record consigliato per servizio e hostname.
- Attendi la propagazione DNS prima di testare HTTPS finale.
Rollback sicuro
Non spegnere il vecchio hosting finché il nuovo hostname non risponde correttamente. Per problemi invia dominio, destinazione attesa e risultato DNS pubblico, non accessi al registrar.
> Tipi di record DNS per i servizi
A/AAAA puntano a indirizzi, CNAME ad alias, MX alla posta e TXT a verifiche, SPF, DKIM o DMARC.
A/AAAA puntano a indirizzi, CNAME ad alias, MX alla posta e TXT a verifiche, SPF, DKIM o DMARC.
Non mescolare record senza motivo
Ogni tipo DNS ha uno scopo. A e AAAA puntano a IP, CNAME crea alias, MX instrada la posta, TXT contiene verifiche e policy mail, CAA limita le autorità certificatrici.
Quando copi record DNS
- Copia nome, tipo e valore esattamente come indicato.
- Non usare CNAME su hostname con altri record se le regole DNS lo vietano.
- Metti DKIM sotto il selettore del fornitore e DMARC di solito sotto _dmarc.
- Configura CAA con attenzione perché può bloccare il certificato.
Se il DNS non funziona
Invia hostname, tipo record, valore atteso e risultato pubblico. Non mandare login al DNS né screenshot con token API.
> Propagazione DNS e TTL senza promesse al minuto
Il TTL indica quanto i resolver possono tenere una vecchia risposta; durante il passaggio vecchi e nuovi risultati possono coesistere.
Il TTL indica quanto i resolver possono tenere una vecchia risposta; durante il passaggio vecchi e nuovi risultati possono coesistere.
La propagazione è cache, non attesa magica
Nel DNS non esiste una promessa precisa al minuto. Dopo una modifica autoritativa, resolver diversi possono restituire vecchie o nuove risposte finché la cache non scade secondo TTL.
Durante un cambio pianificato
- Riduci TTL prima del passaggio se il fornitore lo consente.
- Dopo la modifica evita cambi casuali ripetuti mentre le cache scadono.
- Testa da più resolver se i risultati divergono.
- Annota ora della modifica, valore vecchio, valore nuovo e TTL.
Dati utili alla diagnosi
Indica hostname, destinazione attesa, risposta vecchia visibile, risposta nuova visibile, TTL e ora del cambio. Non inviare accessi DNS o note interne del fornitore.
> Pianificazione storage per Nextcloud
Conta file utenti, cartelle condivise, versioni, cestino, anteprime, sovraccarico di sincronizzazione e crescita del team.
Conta file utenti, cartelle condivise, versioni, cestino, anteprime, sovraccarico di sincronizzazione e crescita del team.
Nextcloud cresce oltre i file visibili
Consumano capacità file utenti, cartelle condivise, file eliminati, versioning, anteprime, miniature, client di sincronizzazione e importazioni. Vicino al limite possono fallire caricamenti e sincronizzazione.
Prima di ordinare capacità
- Somma dati utenti attuali e cartelle comuni.
- Aggiungi margine per versioni, cestino, anteprime e sovraccarico di sincronizzazione.
- Considera import grandi, nuovi team e crescita prevista.
- Aumenta capacità prima che gli utenti tocchino il limite.
Quando la sincronizzazione dà errori
Invia dimensione servizio, utilizzo approssimativo, ora del problema ed errore del client. Non inviare file personali, password o esportazioni utenti salvo canale sicuro richiesto.
> Migrazione repository verso Gitea
Pianifica lo spostamento dei repository con LFS, sottomoduli, permessi, chiavi di deploy, webhook e CI/CD.
Pianifica lo spostamento dei repository con LFS, sottomoduli, permessi, chiavi di deploy, webhook e CI/CD.
Non è solo git clone
Oltre alla storia Git vanno trasferiti o ricreati proprietari, team, rami protetti, tag protetti, Git LFS, sottomoduli, chiavi di deploy, webhook e collegamenti CI/CD.
Controlli prima del passaggio finale
- Elenca repository, proprietari, gruppi di accesso e account di automazione.
- Verifica Git LFS, sottomoduli, protezioni dei rami e protezioni dei tag.
- Dopo il trasferimento testa clone, push, Git LFS, sottomoduli e CI.
- Revoca o ruota i vecchi token senza condividerne i valori.
Dati sensibili nella migrazione
Non inviare token, chiavi private, parte privata delle chiavi di deploy o segreti CI. Bastano nomi repository, tipo integrazione, errore visibile e cosa funzionava prima.
> Dominio mittente per Listmonk
Per le campagne prepara dominio o sottodominio mittente, identità mittente, SPF, DKIM, DMARC, bounce e unsubscribe.
Per le campagne prepara dominio o sottodominio mittente, identità mittente, SPF, DKIM, DMARC, bounce e unsubscribe.
La recapitabilità parte dal dominio
Listmonk richiede una identità mittente chiara e record DNS verificabili. SPF, DKIM e DMARC devono essere coerenti con il dominio o sottodominio da cui invii campagne.
Prima della prima campagna
- Scegli dominio mittente o sottodominio e nome mittente.
- Aggiungi record DNS di verifica, SPF, selettore DKIM e DMARC.
- Testa consegna, bounce o Return-Path e link del messaggio.
- Controlla disiscrizione e List-Unsubscribe prima dell’invio reale.
Segreti mail fuori dai ticket
Per diagnosi invia dominio, tipo record, valore DNS pubblico ed errore. Non inviare password SMTP, token API, chiave DKIM privata o liste destinatari con dati personali.
> Impostazioni Runtime per Classic Hosting
Classic Hosting può usare Runtime auto o manuale; CPU, RAM, storage, conservazione, caricamenti, cache e log influenzano costo e stabilità.
Classic Hosting può usare Runtime auto o manuale; CPU, RAM, storage, conservazione, caricamenti, cache e log influenzano costo e stabilità.
Auto non è sempre la scelta giusta
Auto Runtime aiuta con progetti riconosciuti, ma la modalità manuale è utile per scegliere Nginx, Apache, FrankenPHP o un runtime specifico. Usa PHP selector solo dove supportato dal runtime scelto.
Configurazione prima del deploy
- Scegli Runtime auto o manuale secondo framework e build.
- Seleziona PHP 8.2, 8.3 o 8.4 solo per scenari PHP supportati.
- Imposta CPU, RAM, disco, backup conservazione e Offsite Archive in base a dati e traffico.
- Dopo il deploy testa caricamenti, cache, log ed errori visibili.
Se l’applicazione non parte
Invia modalità runtime, linguaggio o versione PHP, errore visibile, cosa è cambiato e ora approssimativa. Non inviare file .env, password, token o log completi con valori sensibili.