DEV Community: Mohammad Alsaraf

Open a private admin page with an SSH tunnel, no open port needed

Mohammad Alsaraf — Mon, 09 Nov 2026 06:00:00 +0000

Many server apps come with a web page for setup or admin: dashboards, database tools, code editors. Putting those pages on the open internet invites password guessing, and on a NAT VPS every open port is one of your few forwarded ports. An SSH tunnel gives you a third option: the page stays private on the server, and only you reach it, through the SSH connection you already use.

1. Make the app listen only on the server itself

Set your app to listen on 127.0.0.1 (also called localhost) instead of 0.0.0.0. The setting is usually called host, bind or listen address. Then nothing outside the server can reach it. Check with ss:

SSH on port 22 is reachable; the app on 3001 is only reachable from the server itself.

2. Open the tunnel from your computer

On your own computer (Linux, macOS, or Windows 10 and 11 in PowerShell, which include ssh), run:

ssh -N -L 8080:localhost:3001 root@natbox.io -p YOUR_SSH_PORT

-L 8080:localhost:3001: connections to port 8080 on your computer go to port 3001 on the server.
-N: just the tunnel, no shell. Leave the window open while you work; press Ctrl+C to close it.
Use your own SSH port from the client area, the same one you log in with.

3. Open it in your browser

Go to http://localhost:8080. You are looking at the page on your server, carried over the encrypted SSH connection. In our test it is a small private log browser that only listens on 127.0.0.1:

Tips

Several pages at once: add more -L options, for example -L 8080:localhost:3001 -L 8081:localhost:8443.
Save typing: put it in ~/.ssh/config on your computer, then run ssh -N mybox:

Host mybox
    HostName natbox.io
    Port YOUR_SSH_PORT
    User root
    LocalForward 8080 localhost:3001

"Address already in use": something on your computer already uses 8080. Pick another local number, such as 8090.
Over IPv6: you can also connect to your server's IPv6 address on port 22, if your network has IPv6.

Good candidates: the admin page of Uptime Kuma, a database tool for PostgreSQL, or any app you only use yourself. For a public website, use a proper reverse proxy with HTTPS instead: see HTTPS with Caddy.

Get new tutorials in Telegram. Follow @natboxio: every new post, plus short server tips.

Disk full? Find what is filling your server, and clean it up safely

Mohammad Alsaraf — Sat, 07 Nov 2026 06:00:00 +0000

When a disk fills up, apps start failing in odd ways: databases stop writing, updates break halfway, and logins can get slow. Small servers fill up faster, so it pays to know where the space goes. Here is how to find out in a few minutes, and what is safe to delete.

About 10 minutes. Debian and Ubuntu commands; the checks work the same on AlmaLinux and Alpine.

1. How full is the disk?

df -h / shows the size of your disk, how much is used and how much is left. On your server the first column shows your own server's name. The Graphs tab in the client area shows the same number. Above about 85% it is time to clean up.

2. Which folders are big?

du adds up folder sizes. Start at the top and work down into the biggest folder:

The -x keeps du on your disk, and sort -h puts the biggest last.

3. Or browse it with ncdu

ncdu does the same thing with a menu you can move around in with the arrow keys and Enter. Press d on a file to delete it (it asks first) and q to quit.

apt install -y ncdu
ncdu -x /

4. List the biggest files

Usually a few large files are to blame. This lists every file over 100 MB:

Here it is an old backup someone forgot about, and an app log that was never rotated.

5. Clean up safely

Package cache: apt-get clean removes downloaded package files. Always safe.
Old kernels and packages: apt autoremove removes packages nothing needs any more. Read the list before you say yes.
The system journal: journalctl --vacuum-size=50M keeps only the newest 50 MB of logs. See journalctl --disk-usage first.
A huge log file an app still writes to: empty it with truncate -s 0 FILE rather than deleting it. If you delete a file a running program has open, the space is only freed when that program restarts.
Old backups: copy them off the server first (see the backups guide), then delete them.

From 37% to 7% used.

Snapshots use disk space too

Snapshots you take in the client area's Snapshots tab are stored on your server's disk, so a snapshot keeps the files it saved, even after you delete them. If space is tight, delete snapshots you no longer need. More in the docs.

Stop it happening again

Make your app logs rotate: add a file in /etc/logrotate.d/, or log to the journal by running the app as a service (how).
Cap the journal for good: set SystemMaxUse=100M in /etc/systemd/journald.conf, then systemctl restart systemd-journald.
Keep backups off the server, not next to the data they protect.

Still short of space? You can move to a bigger plan from the client area at any time. See the plans.

Get new tutorials in Telegram. Follow @natboxio: every new post, plus short server tips.

Keep commands running after you disconnect, with tmux

Mohammad Alsaraf — Thu, 05 Nov 2026 06:00:00 +0000

You start a big download or a backup over SSH, your Wi-Fi drops, and the command dies with your connection. tmux fixes that: it keeps a terminal running on the server, so you can disconnect, go home, and pick it up again later exactly where it was.

About 5 minutes. Works on any natbox plan. Commands for Debian and Ubuntu; on AlmaLinux use dnf install -y tmux, on Alpine apk add tmux.

1. Install tmux and start a session

Log in to your server (ssh root@natbox.io -p YOUR_PORT), install tmux and start a session with a name you will remember:

apt install -y tmux
tmux new -s download

2. Run your long command inside it

You are now inside tmux: it looks like a normal terminal, with a green bar at the bottom showing the session name. Start anything that takes a while. Here we download a 756 MB Debian image:

The green bar shows you are inside tmux: session download, window 0.

3. Detach, and log out if you like

Press Ctrl+B, let go, then press D. You are back in your normal shell, and tmux tells you the session is still alive. tmux ls lists your sessions. You can now close the window, log out, or lose your connection: the command keeps running on the server.

4. Come back to it

tmux attach -t download

Everything is where you left it. Our download had kept going and was at 94%:

When the command has finished, type exit to close the session.

5. Bonus: two panes side by side

Inside tmux, Ctrl+B then % splits the window in two. Here the left pane follows an app's log with journalctl -fu myapp while the right pane checks memory and disk. Ctrl+B then an arrow key moves between panes.

The keys you need

tmux new -s NAME: start a session. tmux ls: list sessions. tmux attach -t NAME: go back in.
Ctrl+B then D: detach. Ctrl+B then % or ": split side by side or top and bottom.
Ctrl+B then [: scroll back with the arrow keys or Page Up; Q to stop scrolling.

tmux or a service?

tmux is for jobs you start by hand and want to watch: downloads, backups, updates, a game server console. Anything that should run all the time and start again after a reboot, such as a bot or a website, belongs in a systemd service instead: see Keep an app running. A tmux session does not survive a server restart.

No server yet? Try one free for a month.

Get new tutorials in Telegram. Follow @natboxio: every new post, plus short server tips.

Welcome to the natbox blog, and our new video library

Mohammad Alsaraf — Wed, 04 Nov 2026 06:00:00 +0000

natbox runs small Linux servers with root over SSH, your own block of IPv4 ports and a routed /80 of IPv6, from $1.00 a month. This blog is where we will post step-by-step tutorials, longer guides, and news when something changes on our side.

What you will find here

Tutorials: one task from start to finish, with every command, written for a natbox server but useful on any Linux VPS.
Guides: the background to the tutorials, such as how NAT ports and IPv6 work, and how to choose a plan.
Announcements and updates: new features, changes to plans, and anything that affects your server.

Our reference guides stay in Guides, and the basics of your account are in the docs. Blog posts link to them rather than repeat them.

New: videos

We have also put all our videos on one page: natbox.io/video. They play from our own server, with no YouTube embed and no cookies, and the longer ones have English captions.

Our first-server tutorial. Watch it on the video page.

Get a free server and log in over SSH (2:10): start a free trial, log in, change your password, and see how your ports and IPv6 work.
Host a Discord bot 24/7 (1:39): install a bot, keep its token safe, and run it as a systemd service that restarts by itself.
Three Shorts of under 35 seconds, including what a NAT VPS is.

Follow along

Add natbox.io/blog/feed.xml to your feed reader, or follow us on X and YouTube. If there is a tutorial you would like to see, open a ticket or email support@natbox.io.

New to natbox? Try a server free for a month.

What's new at natbox: Telegram bot, snapshots, keeping your trial and CaptchaBox

Mohammad Alsaraf — Wed, 04 Nov 2026 06:00:00 +0000

A lot has changed in the client area over the last few days. Here is everything new, and where to find it.

Manage your servers from Telegram

@NatboxBot lets you check and control your servers from Telegram. Link it from the Telegram page in the client area (account menu, then Telegram ). After that you can:

see each server's status, SSH command, ports, IPv6 address, traffic and paid-until date;
start, stop and restart a server (stop and restart ask you first);
pay an unpaid invoice from your account credit, or open it on the website to pay another way;
get notices for new invoices, payments, support replies, and when a server is set up or a trial is about to end.

The bot also has a small app (the Open app button) with the same features. You can even create an account in the bot. For safety the bot never shows passwords and cannot reinstall a server, and there are no payments inside Telegram.

Snapshots you control

The new Snapshots tab on each server saves the server exactly as it is, for example before a big update, and lets you go back to it later. You can keep 1 snapshot on the free trial and the VPN plan, 2 on Nano, 3 on Box and Box CPU, and 5 on Box Plus. Snapshots use your server's disk space and are stored on the same machine, so keep your own off-site backups as well. The backups guide shows how.

Keep your free trial server

If you like your free trial, you no longer need to start again on a new server. Open the trial in the client area and choose a paid plan to keep it, with all your files and settings. We also email you 7 days and 2 days before a trial ends, so it never ends by surprise.

PayPal from $1

You can now pay with PayPal from $1, so a single month of Nano or Box can be paid directly. Crypto payments start at $3, and account credit works for any amount. The VPN plan and burner servers have their own payment options, listed in the docs.

CaptchaBox: a free captcha for your own sites

CaptchaBox keeps bots out of your website's forms without image puzzles, cookies or Google. Visitors' browsers solve a small puzzle in the background, and your server checks the answer. It is free for 10,000 checks a month, and switching from reCAPTCHA is easy because the server check uses the same answer format. We use it on our own sign-in and sign-up pages.

Watch CaptchaBox in one minute on captcha.natbox.io.

What's next

Follow this blog for tutorials and news, or subscribe with the RSS feed. You can also watch our videos. Questions or ideas: open a ticket.

How a NAT VPS works: shared IPv4, your own ports, and a routed /80 of IPv6

Mohammad Alsaraf — Fri, 30 Oct 2026 22:10:38 +0000

A NAT VPS is a small Linux server that shares one public IPv4 address with other servers. That sounds like a big limitation, but it's what makes a $1 server possible. Here's how the networking works.

Why share an IPv4 address?

IPv4 addresses are scarce and cost money. Most small servers don't need all 65,535 ports on one. A bot, a monitor or a small API often needs just a handful.

Forwarded ports

Each server gets its own block of ports on the shared address, for example 11600 to 11619. The host forwards those ports to the server with destination NAT, so connections arrive directly:

ssh root@example.com -p 11600

Your first port is usually SSH, and the rest are yours for anything, TCP or UDP.

Hosting websites on 80 and 443

Only one machine can own port 443 on an IP address, so how do many servers share it? By hostname. For HTTPS, the browser sends the site name in the TLS handshake (SNI), before anything is encrypted. A proxy on the host reads that name and passes the connection along without decrypting it. Your TLS keys stay on your server.

IPv6 removes the problem

With IPv6 there's no shortage. Each server can get a whole routed /80, which is a huge block of public addresses. Anyone with IPv6 can reach any port directly, with no forwarding.

What you give up

No dedicated IPv4 address
Only the ports in your block on IPv4
Often no Docker, depending on the container setup
Often no outgoing mail on ports 25, 465 and 587, to protect the shared address

When it's a good fit

A NAT VPS suits bots, personal tools, monitoring, small APIs and learning Linux. It's a poor fit if you need a public IP of your own or many inbound ports over IPv4.

I run natbox.io, which offers servers like this from $1 a month, with a free one-month trial: https://natbox.io/?ref=devto

The $0.25 Burner VPS Is the Best Thing I Didn't Know I Needed

Mohammad Alsaraf — Mon, 06 Apr 2026 17:44:36 +0000

Here's a scenario I've been in too many times: I need to test something in a clean Linux environment. Not my laptop — a real server. And I need it for maybe two hours.
My options used to be:

Spin up a DigitalOcean droplet, forget to delete it, notice three weeks later that I've spent $18
Use a Docker container locally, except the whole point is testing how it behaves with real inbound traffic
Ask a friend if I can SSH into something (awkward)
Use some free tier that takes 15 minutes to provision and has weird restrictions
NATBox has a thing called a Burner VPS.

It's $0.25. It lasts 24 hours. After that it's gone — automatically wiped, no lingering data, no grace period, nothing.
I've used it four times now. Twice for testing deployment scripts against a fresh Debian install. Once to spin up a quick reverse proxy for something I was debugging. Once just because I wanted to see what Alpine Linux looks like when you actually have to configure it from scratch.
The workflow is: order it, get SSH credentials in your inbox, do your thing, walk away. You don't have to delete it. You don't have to remember it exists. It costs less than a candy bar.
If you've ever thought "I just need a throwaway server for a few hours" — this is exactly that. The fact that it auto-deletes is actually a feature, not a limitation. No cleanup. No accidentally running up charges. No orphaned droplets sitting around costing you $6/mo because you forgot.
natbox.io, Burner plan, $0.25. I don't know why more hosting providers don't offer this.

I Spent $0.99 on a VPS and Honestly? It Works.

Mohammad Alsaraf — Mon, 06 Apr 2026 17:31:20 +0000

I've been running side projects on the internet for about six years now. In that time I've paid for shared hosting, a few droplets, a couple of hetzner boxes, and one time I rented a dedicated server for something that absolutely did not need a dedicated server. You know how it goes.
A few months ago I needed something small — just a place to run a lightweight Python script that checks a price API every 15 minutes and pings me when something changes. Nothing fancy. The script uses maybe 20MB of RAM when it's running. I did not need a $6/mo DigitalOcean droplet for this. I especially did not need the "recommended" $12/mo plan with 2GB RAM and backups enabled.
I found NATBox while scrolling through some forum thread. Someone mentioned they'd been using it for bots and small automation jobs. The pricing page said $0.99/mo for 256MB RAM, 3GB SSD, and — this part caught my eye — 20 dedicated ports.
I thought: okay, this is probably some sketchy thing running on someone's gaming PC. Let me try it anyway.
What actually happens when you order
The ordering process is manual, which sounds alarming but in practice is fine. You fill out a form, they send you a PayPal or crypto payment link within an hour or two, and once you pay, they provision your container and email you an SSH command. No control panel. No wizard. Just:
ssh root@147.135.215.238 -p [your_port]
And that's it. You're in. Full root. Real Linux.
The ports thing
This is actually the clever part. NATBox runs LXC containers behind a shared IP, so instead of giving you a dedicated public IP, they give you 20 dedicated ports on their host. Port 1 is your SSH. Ports 2-20 forward into your container.
For my use case — a script that doesn't need any inbound connections — this doesn't matter at all. But if you're running a web server, a bot, a game server, a proxy, whatever: you just bind to the port inside your container and it's reachable from the outside world at that port on the host IP. It works.
One month in
The script runs. It has not gone down. I paid $0.99. I have genuinely nothing to complain about.
Would I run a production app with real users here? Probably not — not because of reliability concerns, but because you'd want a dedicated IP, more RAM headroom, and the ability to scale. But for bots, scrapers, learning projects, dev environments, or just having a Linux shell in the cloud? NATBox is legitimately good.
The fact that it exists at $0.99 is kind of wild. I keep expecting to find the catch. So far there isn't one.
Find it at: natbox.io — Nano plan, $0.99/mo

Why I Built a $0.99 VPS and What I Learned

Mohammad Alsaraf — Thu, 26 Mar 2026 10:42:23 +0000

I got tired of paying $5-10/mo for a VPS I only needed to run a bot or test a script. So I built NATBox — NAT-based Linux containers starting at $0.99/mo. Here's what I actually learned building it.
NAT vs dedicated IP — most people don't need a dedicated IP
The whole idea behind NAT VPS is simple: instead of giving each container its own public IP (expensive), you share one host IP and assign each container a dedicated range of ports. 20 ports per container, forwarded via iptables from the host. Port 1 of your range is SSH. Ports 2-20 are yours — run web servers, bots, proxies, whatever.
For most lightweight workloads, this is completely fine. You only need a dedicated IP if you're running something that requires it — like a mail server. For everything else, 20 ports is plenty.
The provisioning stack is a bash script
No Laravel. No Node. No fancy dashboard. The entire backend — create, suspend, renew, delete, expiry checks, email notifications, iptables rules — is a single bash script managing LXC containers and a pipe-delimited flat file as a database.
It's not pretty, but it's reliable, fast, and I understand every line of it. When something breaks at 2am, I can fix it in under 5 minutes.
The weirdest bugs I hit
Building this taught me more about Linux internals than anything else I've done. A few memorable ones:

pam_loginuid.so

was silently killing SSH sessions inside LXC because /

proc/self/loginuid

isn't writable in containers. The fix: comment it out in

/etc/pam.d/sshd

before the container ever boots.
dnf on Fedora was getting OOM-killed inside 256MB containers just resolving package metadata. Fix: pre-create a 512MB swapfile on the host into the container's rootfs before starting it.
OpenSSH 9.2 on Debian 12 calls

linux_audit_write_entry()

during session open, which requires

CAP_AUDIT_WRITE

. I dropped that cap in an earlier version and SSH started dying immediately after auth. One of those bugs that takes an hour to find and 3 seconds to fix.

What $0.99/mo actually gets you
256MB RAM, 3GB SSD, 20 dedicated ports, full root access, your choice of 6 distros. It's a real Linux container, not a toy. I run bots on nano plans. People use them for proxies, learning environments, lightweight APIs, scrapers, testing.
If you want to try it: natbox.io