Skip to content
fastnode_
Portal
menu

platform

The portal: every lever, nothing decorative

You get root on a VMware virtual machine and a portal that handles the things you can't do from inside the box: power, console, disks, network edges.

Built around one question: can you recover?

A server is easy to run when everything works. The portal exists for the other days: the kernel update that didn't boot, the firewall rule that locked you out, the migration that half-finished. Every feature below is something you'd otherwise need to open a ticket for.

FastNode is self-managed. We run the hypervisors, the storage and the network. Inside the operating system, the decisions are yours. The portal is the boundary between those two jobs.

Console

The browser console connects to your server's virtual display, the same view a monitor plugged into a physical machine would show. It does not depend on your server's network stack or on sshd. That's the point.

  • Fix a broken /etc/ssh/sshd_config after a typo.
  • Watch boot messages when a kernel or initramfs change goes wrong.
  • Undo a host firewall rule that dropped your own SSH session.
  • Log in to Windows Server 2025 before Remote Desktop is configured.

Keep a local password for a sudo-capable user even if you only log in with keys over SSH. The console needs a password at the login prompt.

Power

Start, stop and reboot from the portal. A reboot from the portal is the equivalent of pressing the reset button; prefer sudo systemctl reboot from inside the OS when you can, so services get a clean shutdown. Use the portal when the OS no longer responds.

Reinstall

Wipe the disk and lay down a fresh image: Ubuntu 22.04 or 24.04 LTS, Debian 12 or 13, AlmaLinux 9, Rocky Linux 9, or Windows Server 2025. Reinstalling destroys the existing data on that server. Take a snapshot first if there's any chance you'll want something back.

Reinstall is also the fastest way to reset a server you've been experimenting on. Treat servers as replaceable, keep the setup in a script or an Ansible playbook, and a reinstall becomes a two-minute non-event.

Rescue mode

Rescue mode boots your server from a separate recovery environment with your normal disk attached but not running. From there you can mount the filesystem, read logs, fix /etc/fstab, chroot in and repair the bootloader, or copy data out.

# typical rescue session
lsblk                          # find your root partition
mount /dev/vda1 /mnt
mount --bind /dev  /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys  /mnt/sys
chroot /mnt
# repair, then exit, unmount, and leave rescue mode from the portal

Device names vary by image; trust lsblk over memory.

Snapshots and scheduled backups

Snapshots capture the server's disk at a moment you choose. Take one before an OS upgrade, a schema migration or a config overhaul. If it goes wrong, roll back.

Backups run on a schedule you set in the portal. They're the routine safety net for the mistakes you don't see coming. For anything you truly can't lose, keep a third copy somewhere you control off the server, and test a restore at least once. Our backup guide covers a layered approach and database-consistent dumps.

Firewall

Per-server firewall rules in the portal filter traffic before it reaches your operating system. They're useful for broad policy: allow 22 from your office or VPN, 80 and 443 from anywhere, drop the rest. A host firewall handles finer detail and application-specific rules.

Two layers means two places to look when a port seems closed. Check the portal rules first, then sudo nft list ruleset or sudo ufw status verbose on the host. See the nftables guide.

Reverse DNS

Set the PTR record for your server's IPv4 address from the portal. Point it at a hostname whose A record resolves back to the same IP. Mail delivery depends on this; logs and monitoring are tidier with it.

SSH keys and root password

Store public keys in the portal and have them installed on new builds and reinstalls, so a fresh server is reachable by key from its first boot. If you lose a password, reset root from the portal and log in through the console. Then rotate it and get back to keys. The SSH hardening guide covers locking down sshd after first login.

Stats

CPU and bandwidth graphs per server show the shape of your load over time. They're coarse by design: enough to spot a runaway process or a traffic spike, not a replacement for real monitoring. For per-process detail and alerting, run your own agent; we explain a lean setup in the monitoring guide.

Port 25

Outbound SMTP on port 25 is blocked by default on every server. Most applications should send mail through an authenticated relay on port 587 anyway. If you run your own mail server, request an unblock in the portal and make sure your reverse DNS, SPF, DKIM and DMARC are in order first.

Automating all of this

Account API keys and webhooks live in the portal too. Use them to wire FastNode into scripts and pipelines; details on the API page.

Questions

Can I reach my server if SSH is broken?

Yes. The browser console attaches to the virtual display, so you can log in at the local prompt even when networking or sshd is misconfigured. Rescue mode covers the cases where the installed system won't boot.

What is the difference between a snapshot and a backup?

A snapshot is a point-in-time copy you take by hand, typically right before a risky change. Backups run on a schedule you set. Use snapshots for rollbacks and backups for routine recovery; keep an off-server copy of anything you cannot lose.

Why is outbound port 25 blocked?

Compromised servers sending spam damage the reputation of every address on a network. Port 25 is closed by default and you can request an unblock from the portal once you have a legitimate mail use.

Does the portal firewall replace a host firewall?

No. Portal rules filter traffic before it reaches your server; a host firewall such as nftables or ufw filters on the server itself. Running both is sensible: the portal for broad edges, the host for detail.