Installazione e configurazione di 1Panel

Installazione di 1Panel su Linux: scelta dell’host e prerequisiti

1Panel è utile quando vuoi un pannello web leggero per gestire servizi, container, domini, certificati e backup senza dover costruire tutto a mano. La parte importante non è l’installazione in sé: è decidere dove metterlo e come esporlo. Trattalo come un servizio di amministrazione, quindi con accesso ristretto, rete pulita e un piano di rollback prima ancora di aprire la UI.

Su un server Linux recente, il requisito pratico è semplice: una macchina con systemd, accesso root o sudo, connettività in uscita per scaricare il pacchetto e spazio disco sufficiente per dati, log e immagini container. Se il server ospita già siti o database, considera il blast radius: 1Panel non deve competere con le porte dei servizi esistenti né rubare risorse a runtime critici.

Prima di toccare il sistema, verifica tre cose: architettura CPU, stato delle porte e spazio libero. Sono controlli banali, ma ti evitano installazioni incomplete o un pannello che parte e poi fallisce al primo riavvio.

Comandi base di verifica:

uname -m
lsblk
free -h
df -h
ss -lntp

Atteso: architettura coerente col pacchetto che installerai, almeno qualche gigabyte libero sul filesystem che ospiterà i dati di 1Panel, e nessuna collisione sulle porte che vuoi usare per UI e servizi correlati.

Se il server è già pubblico, pianifica subito il controllo dell’accesso alla porta del pannello: esporla su Internet senza restrizione è la scorciatoia più comune verso problemi evitabili.

Installazione: metodo rapido e cosa controllare subito dopo

La distribuzione di 1Panel usa in genere uno script ufficiale o un pacchetto che automatizza installazione e servizi. Il punto operativo non cambia: stai avviando un demone che crea directory, configura un servizio e apre una porta di amministrazione. Per questo conviene sempre leggere lo script o il pacchetto prima di eseguirlo, soprattutto in ambienti di produzione o su macchine condivise.

Se usi lo script di installazione, eseguilo da shell con privilegi elevati solo dopo averne verificato origine e versione. Non copiare e incollare comandi trovati in giro senza capire che cosa installano: il rischio non è teorico, perché un pannello di amministrazione ha accesso a servizi e file sensibili.

curl -fsSL https://resource.fit2cloud.com/1panel/package/v2/quick_start.sh -o quick_start.sh
sed -n '1,220p' quick_start.sh
bash quick_start.sh

Se il comando del pacchetto cambia nel tempo, il punto resta lo stesso: scarica, ispeziona, poi esegui. Se non hai una fonte ufficiale verificabile, fermati e recupera il link dalla documentazione del progetto o dal repository ufficiale. Questo è il modo corretto di chiudere un gap informativo, non di improvvisare.

Dopo l’installazione, verifica che il servizio sia attivo e che la porta del pannello risponda localmente. Il controllo deve essere fatto prima di aprire firewall o reverse proxy, così distingui un problema di servizio da un problema di rete.

systemctl status 1panel --no-pager
ss -lntp | grep -E '1panel|:xxxx'
curl -I http://127.0.0.1:PORTA

Atteso: servizio active (running), socket in ascolto sulla porta prevista e risposta HTTP coerente con la schermata di login o con un redirect verso HTTPS, se già configurato. Se il servizio non parte, il primo posto da guardare è il journal:

journalctl -u 1panel -xe --no-pager

Qui trovi il motivo reale del fallimento: porta occupata, permessi mancanti, directory non scrivibile, dipendenze mancanti o errore nella generazione della configurazione iniziale.

Hardening iniziale: porta, firewall, accesso amministrativo

La configurazione corretta non è “installato e raggiungibile da ovunque”. Il pannello va trattato come un servizio di controllo: accesso limitato, idealmente dietro VPN o almeno con IP allowlist e HTTPS valido. Se lo esponi direttamente, riduci almeno la superficie d’attacco con regole firewall e credenziali robuste.

La prima azione è verificare quali porte apre realmente 1Panel. Non dare per scontato che usi quelle che hai in mente: controlla il file di configurazione o l’output del setup, poi allinea firewall e reverse proxy di conseguenza.

grep -RniE 'port|listen|address' /opt/1panel /usr/local/bin 2>/dev/null | head -n 20

Se usi ufw, apri solo la porta necessaria e solo se hai già deciso il perimetro di accesso:

ufw allow from 203.0.113.10 to any port PORTA proto tcp
ufw status numbered

Con firewalld il concetto è identico: consenti il minimo indispensabile e documenta l’eccezione. In ambienti server seri, meglio ancora mettere il pannello dietro un reverse proxy con TLS e restrizione per subnet o autenticazione aggiuntiva.

Se il tuo obiettivo è operare in sicurezza, la sequenza giusta è questa: prima rendi accessibile solo da rete fidata, poi cambi password iniziale, poi abiliti HTTPS, infine valuti eventuali integrazioni con SSO o accesso via VPN. Saltare i primi due passaggi è un errore classico.

Assunzione pratica: il server è in produzione o comunque esposto a utenti reali fino a prova contraria. Per questo ogni modifica a firewall, porta o certificato va fatta con rollback pronto.

Primo accesso alla UI e configurazione iniziale

Al primo login, cambia subito le credenziali iniziali e verifica che l’utente amministrativo sia l’unico con privilegi completi. Se il pannello supporta più account o ruoli, crea subito un account operativo separato da quello di emergenza. È una misura semplice che ti evita di usare sempre lo stesso superuser per tutto.

La UI di 1Panel serve per gestire rapidamente container, siti, database, backup e certificati. Anche se è comoda, non usare la comodità come sostituto della tracciabilità: annota sempre dove salva i dati, quali directory usa e quale porta espone. La parte importante, in caso di guasto, è sapere dove andare a leggere i file reali.

Controlla questi elementi subito dopo il primo accesso:

1. versione del pannello, per sapere se sei allineato con eventuali bug noti;
2. porta e indirizzo di ascolto, per evitare conflitti con altri servizi;
3. directory dati, per pianificare backup e snapshot;
4. stato del servizio, per verificare che un reboot non rompa l’installazione.

Se la UI mostra un errore di connessione a componenti interni, non cambiare tre cose insieme. Prima identifica il layer: servizio locale, rete, database interno o storage. Un pannello amministrativo sembra “rotto” molto spesso per un problema banale di file system pieno o permessi errati.

Backup e rollback: la parte che salva il tempo quando qualcosa si rompe

Prima di fare qualsiasi personalizzazione, definisci un backup minimo. Per 1Panel questo significa almeno salvare la directory dati, la configurazione del servizio e l’elenco dei container o delle app gestite. Se il sistema è già in produzione, aggiungi anche uno snapshot del volume o una copia a livello filesystem, a seconda dell’infrastruttura disponibile.

Un backup utile non è quello che esiste, ma quello che puoi ripristinare. Quindi verifica subito il percorso reale dei dati e fai un test di restore su una macchina non critica o in una directory temporanea. Se non sai dove sono i dati, il backup è solo un file in più.

systemctl cat 1panel
find / -maxdepth 3 -type d -name '*1panel*' 2>/dev/null
ls -lah /opt/1panel

Per il rollback, l’approccio minimo è semplice: conserva il pacchetto/script usato per installare, esporta la configurazione corrente e documenta la porta e il metodo di avvio. Se una modifica rompe la UI o il servizio, devi poter tornare alla versione precedente senza ricostruire tutto da zero.

In pratica, il rollback ragionevole è: fermare il servizio, ripristinare la directory dati o il file di configurazione salvato, riallineare i permessi e riavviare. Se hai fatto modifiche a firewall o reverse proxy, quelle vanno riportate allo stato precedente nello stesso ordine in cui le hai applicate.

Integrazione con reverse proxy e TLS

Se vuoi esporre 1Panel in modo serio, mettilo dietro Nginx, Apache o un proxy dedicato e termina TLS lì. Questo ti permette di centralizzare certificati, redirect HTTPS, header di sicurezza e restrizioni di accesso. In molti casi è anche più semplice mantenere il pannello dietro una porta locale e pubblicare solo il proxy.

La logica è questa: 1Panel ascolta in locale o su una rete privata, il proxy espone il dominio pubblico, e il certificato viene gestito sul livello esterno. Se il certificato scade o il DNS cambia, il pannello resta protetto e il problema si isola meglio.

Un esempio di proxy minimale con Nginx, da adattare alla tua porta reale:

server {
    listen 443 ssl http2;
    server_name panel.example.com;

    ssl_certificate     /etc/letsencrypt/live/panel.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/panel.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:PORTA;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Dopo il reload del proxy, verifica in modo esplicito:

nginx -t
systemctl reload nginx
curl -Ik https://panel.example.com

Atteso: test di configurazione OK, reload senza errori e risposta TLS corretta con certificato valido. Se il browser mostra errore di certificato, controlla DNS, chain e percorso dei file prima di toccare il pannello.

Problemi tipici dopo l’installazione e come leggerli in fretta

Il caso più frequente è il pannello che non si apre. Le cause reali, quasi sempre, sono poche: porta occupata, servizio non attivo, firewall, certificato errato o spazio disco insufficiente. L’ordine corretto di verifica è sempre dal layer più basso a quello più alto: servizio locale, rete, proxy, browser.

Se la pagina è bianca o incompleta, non pensare subito a un bug dell’interfaccia. Controlla prima i log del servizio e del browser, poi verifica se il backend risponde davvero. Se il pannello usa componenti containerizzati, guarda anche lo stato dei container collegati.

journalctl -u 1panel --since "1 hour ago" --no-pager
docker ps -a
ss -lntp
df -h

Se trovi errori di permesso, il problema di solito è una directory dati non scrivibile o un mount montato con opzioni sbagliate. Se trovi errori di rete, spesso è il firewall che blocca la porta o un proxy configurato con upstream errato. Se il disco è pieno, il sintomo può essere qualsiasi cosa: login che fallisce, aggiornamenti che non partono, backup interrotti.

Per gli aggiornamenti, la regola è la stessa di ogni componente amministrativo: prima leggi release note o changelog, poi fai backup, poi aggiorni. Evita update “alla cieca” su sistemi che gestiscono più siti o container. Un upgrade del pannello non deve diventare un incidente che ferma mezzo host.

Checklist operativa finale per un’installazione pulita

Se vuoi chiudere l’installazione in modo ordinato, questa è la sequenza minima che ha senso seguire:

1. verifica architettura, spazio disco e porte libere;
2. scarica e controlla il metodo di installazione da fonte affidabile;
3. installa il servizio e conferma che sia active (running);
4. limita l’accesso con firewall o VPN;
5. cambia subito le credenziali iniziali;
6. abilita TLS tramite reverse proxy o certificato valido;
7. definisci backup e prova un ripristino minimo;
8. documenta porta, path dati, comando di avvio e rollback.

Questa sequenza è più importante della procedura “perfetta”, perché ti mette in condizione di diagnosticare il problema senza andare a tentoni. In un pannello di amministrazione, la qualità dell’installazione non si misura solo dal fatto che la UI si apra, ma dal fatto che tu riesca a ripristinarla e governarla senza stress.

Se devi portare 1Panel in produzione, l’obiettivo reale non è “installarlo”. L’obiettivo è avere un punto di controllo stabile, documentato e recuperabile. Tutto il resto è rumore.