Arch Linux pre-installato su ogni fascia, con pacman, l'AUR e una mirrorlist nordica pronti al primo avvio. Ricostruito ogni 14 giorni così un deploy fresco non è mai più di due settimane lontano da un -Syu corrente. Kernel stock, nessuna patch NordBastion.
Immagini Arch pre-installate su ogni fascia — base, minimal, Wayland-headless e Docker — ricostruite ogni 14 giorni.
Pacman, AUR, kernel upstream stock — nessuna patch NordBastion, nessun lock-in LTS, nessun re-impacchettamento di opinione.
Ancorato a una delle quattro giurisdizioni costituzionali nordiche — Svezia, Finlandia, Norvegia o Islanda — pagato in Bitcoin o Monero.
Nessun congelamento stabile, nessun ritardo LTS di due anni, nessuna archeologia di backport. Quando upstream Linux distribuisce 6.11 lei ottiene 6.11 in pochi giorni, non diciotto mesi dopo come compilazione Debian-backports. Per i carichi di lavoro che dipendono da una funzionalità recente — io_uring, tracepoint eBPF, un nuovo target netfilter — Arch è la distanza più breve da upstream.
Arch non include nulla che non abbia chiesto. Il gruppo base è un paio di centinaia di pacchetti, tutti espliciti; non c'è una fascia «raccomandata» che tira silenziosamente uno stack desktop su un server. Compone il sistema che davvero vuole con pacman, e l'immagine risultante è auditabile — ogni binario su disco è tracciabile a un pacchetto che ha installato.
L'Arch User Repository è la coda lunga — strumenti da riga di comando di nicchia, pacchetti vendor, runtime beta che nessun'altra distribuzione ha ancora preso. I PKGBUILD sono brevi script shell che può leggere prima di eseguire; su un VPS a singolo operatore dove già auditta tutto, l'AUR è più vicino a «legga questa ricetta di build di cinque righe» che a un binario vendor a scatola chiusa.
| Immagine | Slug | Caso d'uso |
|---|---|---|
| Arch base (rolling) | arch-base |
L'immagine di riferimento — un pacman -Syu corrente del gruppo base ufficiale archlinux con openssh abilitato. La scelta predefinita per un nuovo server Arch. |
| Arch minimal-base | arch-min |
Spogliata ulteriormente rispetto a base — niente man-page, niente documentazione, niente utility raccomandate. ~330 MB per l'operatore che ricorre a pacman da sé al primo avvio. |
| Arch + Wayland (headless) | arch-wayland |
Wayland + wlroots + Sway pre-installati, ottimizzata per testing grafico headless, automazione browser sotto wayvnc o workstation di sviluppo remote. |
| Arch + Docker | arch-docker |
docker, docker-compose e il collante iptables-nft pre-configurati — pacman mantiene l'engine sulla cadenza upstream, nessun repo vendor separato da cablare. |
ISO personalizzata montabile per archlinux-bootstrap o qualsiasi derivata (Artix, EndeavourOS, CachyOS) su richiesta — senza ticket via il pannello.
Rolling release, niente LTS, niente archeologia di backport, AUR per la coda lunga. Il costo è la disciplina rolling — pacman -Syu è un'abitudine settimanale deliberata, non un cron job non presidiato.
Tooling apt della famiglia Debian con i PPA e la documentazione vendor che mirano a Ubuntu LTS. La via di mezzo facile tra l'edge-upstream di Arch e il conservatorismo di Debian. Veda /ubuntu-vps/.
Finestra di supporto di cinque anni, set di pacchetti conservativo, nessuna sorpresa. Il default noioso-corretto per produzione e sidecar. Veda /debian-vps/.
2 vCPU, 4 GB RAM, 120 GB NVMe. Arch minimal qui fa girare un servizio a singolo scopo — un reverse proxy Caddy, un relay Tailscale, un worker yt-dlp — vicino a upstream senza bloat.
4 vCPU, 8 GB RAM, 240 GB NVMe. Il punto ottimale per un host Arch + Docker che fa girare uno stack di container auto-build, o un build-server che usa l'AUR per compilare un runtime personalizzato.
8 vCPU, 16 GB RAM, 480 GB NVMe. Comodo per un'immagine Wayland-headless che guida l'automazione browser, un laboratorio annidato Arch + KVM o una workstation di sviluppo personale nel cloud.
Linea fasce completa — Sentinel · Garrison · Ravelin · Bulwark · Citadel — su /vps/.
Per un operatore che tratta il proprio server come un'officina — un build host, un nodo relay, un laboratorio Wayland-headless, una workstation cloud personale — Arch su NordBastion le dà il kernel di oggi, la userland di oggi e un sistema vuoto su cui comporre. L'abbinamento con un host nordico senza KYC è coerente: due sistemi che si rifiutano di fare scelte implicite per lei e si aspettano che le faccia esplicite lei stesso.
Scelga Debian se vuole dimenticare il server. Scelga Ubuntu se il suo runbook già presuppone apt + PPA. Scelga Arch quando vuole davvero vivere vicino a upstream e accetta il costo.
Le domande che gli operatori pongono realmente prima di far girare una distribuzione rolling-release su un host privacy-first.
Arch è una distribuzione desktop nel senso che la maggior parte della sua comunità visibile la fa girare su workstation, ma il sistema sottostante — pacman, systemd, una base minimale, nessuna scelta init di opinione — è in effetti estremamente adatto a un VPS a singolo operatore dove vuole un kernel recente, una userland recente e nessun freeze LTS che sta tra lei e upstream. La ragione per cui è meno comune sui server è la disciplina rolling che richiede, non una limitazione tecnica.
Ogni 14 giorni, in linea con la cadenza mensile ufficiale archlinux-bootstrap più un refresh a metà ciclo. Un VPS Arch appena distribuito sarà già entro due settimane di un pacman -Syu corrente — così gli aggiornamenti al primo avvio sono minuti, non ore, e quasi mai incontra un problema di keyring obsoleto al primo giorno.
Sì. yay e paru non sono pre-installati (la convenzione Arch è che lei scelga il proprio helper), ma l'AUR è pienamente raggiungibile, makepkg funziona contro lo stock /etc/makepkg.conf, e il firewall NordBastion non blocca aur.archlinux.org né alcun mirror Arch. I repo binari ufficiali coprono la maggior parte delle necessità server; l'AUR riempie la coda lunga.
No, e non può esserci — Arch è esplicito che gli upgrade parziali sono non supportati e l'archivio dei pacchetti non garantisce la ritenzione delle vecchie versioni. Il workflow raccomandato su NordBastion è lo stesso del bare metal: faccia uno snapshot del VPS via pannello prima di pacman -Syu, esegua l'upgrade, riavvii e rolli indietro dallo snapshot se qualcosa nel suo stack non sopravvive. Gli snapshot sono una singola azione dal pannello; il rollback è grosso modo 30 secondi.
linux dal repo core — il kernel stable upstream corrente come impacchettato da Arch, nessuna patch NordBastion. linux-lts è una pacman install di distanza se vuole il branch long-term, e può tenere entrambi installati in parallelo e selezionare tra loro al boot via systemd-boot. mkinitcpio è il generatore di initramfs di default.
Onestamente, non davvero. Arch ricompensa un operatore che tratta pacman -Syu come un'abitudine settimanale deliberata e legge /var/log/pacman.log dopo ogni transazione. Se vuole un server che non chiede nulla per anni alla volta, Debian (veda /debian-vps/) è l'abbinamento corretto su NordBastion — Arch è l'abbinamento corretto quando vuole davvero essere vicino a upstream e accetta il costo.
Sì. /etc/pacman.d/mirrorlist è pre-generato con reflector al momento del build dell'immagine, classificando per velocità dal punto di vista del bastione — la cima della lista è tipicamente un mirror svedese o finlandese (mirror.osbeck.com, mirror.f4st.host, ftp.acc.umu.se). Può ri-eseguire reflector in qualsiasi momento per ri-classificare se il suo carico di lavoro cambia.
Sì — KVM tratta il suo disco virtuale come un disco reale, e systemd-boot o grub di Arch caricheranno volentieri a catena un altro OS installato in una seconda partizione. Il pattern più comune su NordBastion, tuttavia, è di provisionare due istanze VPS piccole separate per i due sistemi; il costo è simile a un dual-boot più grande e le modalità di fallimento sono indipendenti.
