Skip to main content

Server Stack

@randybias/server-stackv2026.10.17.5beta· 9d agoWORKFLOWS
01README

Provision and tear down a hardened single-node k0s host on a WireGuard mesh, running NATS and published in Cloudflare DNS, by composing the server, SSH, mesh, hardening, cluster and secret model types. Workflows only: the package ships no models of its own, and every instance value arrives as a workflow input.

02Workflows2
@randybias/server-stack-provision-host81b1bccb-23ec-4703-8e09-e97a8591e1b2

Build a hardened k0s host running NATS on the mesh, then publish its DNS

preflightCheck inputs and probe Cherry and Cloudflare before anything is created
1.check-inputs— Check cross-input invariants before any remote call
2.probe-server${{ inputs.server_model }}.list— List the project's servers via the Cherry Servers API
3.check-cloudflare-token— Read the zone via the Cloudflare API to prove the token works
4.probe-record— List the target A record via the Cloudflare API
5.refuse-existing— Refuse an existing server or record unless adopt is set
hostOrder the server, wait for SSH, and join it to the mesh
1.create${{ inputs.server_model }}.create— Order or adopt the server via the Cherry Servers API
2.check-adopt-ownership— Check an adopted server carries the ownership tag
3.wait-ready${{ inputs.server_model }}.wait_ready— Wait for SSH with pinned host keys via the Cherry Servers model
4.apply-base— Apply base packages, admin user and sysctl via SSH
5.join-mesh— Render and push the node's WireGuard config via SSH
6.wait-mesh— Wait, bounded, until the mesh address answers so the first handshake has happened
7.verify-mesh— Read the node's WireGuard peers and handshakes via SSH
8.check-mesh— Check a recent mesh handshake exists before any firewall change
hardenApply the firewall and lockdown, committing only after fresh reachability
1.apply-firewall— Apply the nftables ruleset with a revert armed first
2.verify-firewall— Verify SSH answers over the mesh after the firewall
3.commit-firewall— Commit the firewall by cancelling its armed revert
4.lockdown— Close public SSH to the management CIDRs with a revert armed
5.verify-lockdown— Verify SSH answers over the mesh after the lockdown
6.inspect-lockdown— Read the recorded firewall and exposure state via SSH
7.check-lockdown— Check SSH exposure is management-only before committing
8.commit-lockdown— Commit the lockdown by cancelling its armed revert
clusterInstall k0s, write the kubeconfig, and run the secrets and NATS chart
1.install-k0s— Install the SHA-pinned k0s binary and start the node via SSH
2.wait-k0s— Wait for the node and system pods to be Ready
3.check-k0s— Check the node and system pods are Ready
4.kubeconfig— Write the admin kubeconfig to the vault via k0s
5.check-kubeconfig— Check the kubeconfig server is the node's route address
6.apply-namespaces— Create the cluster namespaces via the k0s manifest deployer
7.apply-secrets— Write each cluster Secret from vault values via kubectl stdin
8.check-nats-token— Check the NATS auth token is YAML-safe before it is written into a manifest
9.apply-nats-auth— Write the NATS auth token Secret on the host through the k0s manifest deployer
10.apply-nats— Reconcile the NATS chart via the k0s Helm extension
11.apply-nats-after-secrets— Reconcile the NATS chart via the k0s Helm extension
verifyProve NATS answers over the mesh before any DNS is published
1.probe-nats— Read the NATS INFO banner over the mesh via a TCP probe
2.probe-nats-auth— Probe NATS with the token, then prove a connection without it is refused
3.check-nats— Check the banner is NATS INFO with the expected server name and, with auth on, that auth is enforced
publishCreate and verify the host's A record only after NATS answers
1.create-record— Create the host's A record via the Cloudflare API
2.verify-record— Re-list the record and check it points at the host
3.check-record— Check the record points at the host and carries the marker
@randybias/server-stack-teardown-host6c053a9b-a13b-4f48-bf92-76e1f049e5df

Remove a provisioned host's DNS record, k0s cluster and server

teardownRemove DNS, reset k0s, delete the server, and verify both APIs
1.check-inputs— Check the hostname confirmation before any change
2.sync-server${{ inputs.server_model }}.list— Refresh the recorded server via the Cherry Servers API
3.check-ownership— Refuse a server that lacks the ownership tag
4.find-record— List the host's A record via the Cloudflare API
5.check-record— Refuse a record without this host's ownership marker
6.dns-safety-ok— Assert the DNS safety gate passed when DNS is enabled
7.delete-record— Delete the host's A record via the Cloudflare API
8.reset-k0s— Stop and reset k0s over the mesh via SSH
9.delete-server${{ inputs.server_model }}.delete— Delete the server after hostname and project checks
10.verify-cherry${{ inputs.server_model }}.list— List the project's servers to confirm none match this hostname
11.check-cherry— Check no server with this hostname remains in the project
12.forget-public-record— Delete the public-address record kept for the removed host via server-host
13.forget-mesh-record— Delete the mesh-address record kept for the removed host via server-host
14.verify-dns— List the zone's A records to confirm none match this name
15.check-dns— Check no record with this name remains in the zone
03Previous Versions2
2026.10.17.4
2026.10.17.3
04Stats
A
93 / 100
Downloads
2
Archive size
17.8 KB
  • Has README or module doc2/2earned
  • README has a code example1/1earned
  • README is substantive1/1earned
  • Most symbols documented1/1earned
  • No slow types (deprecated)1/1earned
  • Dependencies pass trust audit2/2earned
  • Has description1/1earned
  • Platform support declared (or universal)2/2earned
  • License1/2partial

    no SPDX license declared

  • Verified public repository2/2earned
05Platforms
06Labels