DEV Community: VeloxaHost

Harden a fresh Ubuntu 24.04 server with one command (open source)

VeloxaHost — Thu, 05 Nov 2026 18:27:25 +0000

Every new VPS gets the same first hour: create a user, lock down SSH, set up a firewall, install fail2ban, turn on automatic updates… and then forget one of them on the next server.

So we turned our checklist into a small open-source script: veloxahost/server-hardening. One command, readable configs, safe to re-run.

What it does

Creates a sudo user and installs your SSH key
SSH: keys only, no root login, no passwords — via a drop-in file, validated with sshd -t before restart
UFW: deny inbound, rate-limit SSH, allow 80/443
fail2ban with the systemd backend (the reliable choice on Ubuntu 24.04) and escalating bans
Unattended security upgrades + needrestart
auditd rules for identity files, sudoers, sshd config and root commands
Kernel sysctl hardening that doesn't break Docker
A Lynis audit at the end so you get a score

Usage

On a fresh Ubuntu 24.04 server (22.04 and Debian 12 work too), keep your current session open and run:

git clone https://github.com/veloxahost/server-hardening.git
cd server-hardening
sudo NEW_USER=deploy SSH_KEY="ssh-ed25519 AAAA... you@example.com" ./harden.sh

Then open a new terminal and check ssh deploy@your-server works before logging out.

Options are plain environment variables:

Var	Default	Meaning
`NEW_USER`	`deploy`	sudo user to create
`SSH_KEY`	required	public key for that user
`SSH_PORT`	`22`	SSH port to allow
`ALLOW_PORTS`	`80,443`	extra TCP ports to open
`ENABLE_IP_FORWARD`	`0`	set `1` on Docker hosts
`RUN_LYNIS`	`1`	run the audit at the end

Three things people get wrong on Ubuntu 24.04

1. Editing sshd_config directly. 24.04 reads /etc/ssh/sshd_config.d/*.conf first. Put your settings in a drop-in so package upgrades never overwrite them.

2. fail2ban watching a log file that's empty. SSH logs go to the journal now. Use backend = systemd or your sshd jail will show zero failures forever.

3. Trusting UFW with Docker. Ports published with -p 8080:8080 bypass UFW completely. Bind internal services to 127.0.0.1 and put a reverse proxy in front.

Why not Ansible?

If you already run Ansible, use it. This is for the "one server, five minutes" case: a single bash script you can read top to bottom before you run it as root.

Full write-up with every command explained: The Complete Linux Server Hardening Checklist (2026)
Production Docker Compose stacks with automatic HTTPS: veloxahost/compose-stacks

PRs and issues welcome — especially for other distros.

Disclosure: I work on VeloxaHost, a hosting platform. The script is MIT-licensed and works on any Linux server.

Run Docker inside Incus system containers (profiles + cloud-init)

VeloxaHost — Thu, 05 Nov 2026 18:25:15 +0000

If you've only used Docker on a VM, you may not know you can run it inside a system container — no hypervisor, near-native speed, and it boots in a couple of seconds. Incus (the community fork of LXD) makes this easy once you know the three settings that matter.

All configs below are in veloxahost/incus-examples.

The profile

description: Run Docker inside a system container
config:
  security.nesting: "true"
  security.syscalls.intercept.mknod: "true"
  security.syscalls.intercept.setxattr: "true"
  linux.kernel_modules: overlay,br_netfilter,ip_tables,ip6_tables,nf_nat,xt_conntrack

security.nesting lets the container create its own containers.
The two syscall intercepts let Docker's overlay filesystem and image layers work in an unprivileged container.
linux.kernel_modules makes sure the host loads what Docker networking needs.

Load it:

incus profile create docker-ready
incus profile edit docker-ready < profiles/docker-ready.yaml

Launch with cloud-init

The repo's cloud-init/docker-host.yaml installs Docker Engine and the Compose plugin from Docker's apt repo and sets sane log rotation:

incus launch images:ubuntu/24.04/cloud web-01 \
  -p default -p docker-ready \
  --config cloud-init.user-data="$(cat cloud-init/docker-host.yaml)"

incus exec web-01 -- cloud-init status --wait
incus exec web-01 -- docker run --rm hello-world

Add limits

Don't let one container eat the host:

config:
  limits.cpu: "1"
  limits.memory: 1GiB
  limits.memory.enforce: hard
  limits.processes: "2000"

Snapshots before every upgrade

./scripts/snapshot-rotate.sh web-01 7   # take one, keep the newest 7

Run it from cron and docker compose pull && docker compose up -d stops being scary.

Container or VM?

	System container	VM
Boot	~1–3 s	~10–30 s
Overhead	near zero	full kernel
Docker inside	yes (nesting)	yes
Custom kernel modules	no	yes

For web apps, databases and Compose stacks, a container is usually the better trade.

Don't want to run the host?

That's essentially what a VeloxaHost server is: a root system container that runs Docker, from $4/mo with snapshots and an API.

Disclosure: we run VeloxaHost. The repo is MIT and works on any Incus host.

30 AI website builder prompts that produce usable sites (free, CC0)

VeloxaHost — Thu, 05 Nov 2026 18:19:41 +0000

Most "build me a website" prompts produce the same generic page: a hero, three feature cards, lorem ipsum. The fix isn't a longer prompt — it's a more specific one.

We put together a library of specific, structured prompts built on six simple rules: veloxahost/veloxa-build-prompts — 30 prompts, CC0, works in Lovable, Bolt, v0, Replit or Veloxa Build.

The 6 rules behind every prompt

Name the business. "Rise & Crumb bakery" gets you real copy; "a bakery" gets you filler.
List sections in order. The AI follows your structure instead of inventing one.
Spell out every form field. "A pre-order form (name, phone, pickup date, items)" beats "a contact form".
Give it a look. Two or three colours, a mood word, and "mobile first".
Say where data lives. For mini-apps, "save in the browser" avoids half-built backends.
Iterate one change at a time. Small follow-ups beat one 2,000-word prompt.

Three examples

Local business (plumber):

Build a website for a local plumbing company "FlowRight Plumbing". Hero with a big 'Call now' button and emergency 24/7 badge, services grid (leaks, water heaters, drains, remodels), service-area list of towns, a quote request form with photo upload, trust badges section (licensed, insured, years in business) and a reviews section with placeholder text.

SaaS waitlist:

Build a landing page for a SaaS product "ShipNote" that turns git commits into release notes. Sections: hero with a headline, subheadline and email waitlist form, a 3-feature grid with icons, a 'how it works' diagram in 3 steps, pricing teaser (Free, Pro), FAQ and footer. Show a success message after signup. Modern, purple accent.

Working mini-app (expense splitter):

Build an app to split group expenses. Create a group, add people, add expenses (who paid, amount, who shares it, equal or custom split), and show balances plus the minimum set of payments to settle up. Mobile first, save in the browser, export a summary as text.

What's in the repo

Small-business sites: bakery, restaurant, salon, contractor, accountant, real estate, trainer, therapist
Personal: designer and developer portfolios, link-in-bio, résumé, wedding RSVP
Startup/SaaS: waitlist, product launch, pricing page, changelog, status page
Apps: habit tracker, invoice generator, to-do, expense splitter, RSVP manager, flashcards, booking page, memory game
Community: nonprofit, club, tutor, band

Every prompt has a one-click button that drops it into the builder's message box without sending, so you can tweak it first.

Got a prompt that works well? Open a PR.

Disclosure: we build Veloxa Build. The prompts are CC0 and builder-agnostic.

How to host a Lovable, Bolt or v0 app on your own domain (configs included)

VeloxaHost — Thu, 05 Nov 2026 18:18:54 +0000

You built an app in Lovable, Bolt or v0, clicked export, and now you have a zip or a GitHub repo. Getting it onto your own domain is where most people get stuck — blank pages, routes that 404 on refresh, env vars that vanish.

We collected the configs we use into an open-source repo: veloxahost/host-ai-built-apps. Here's the short version.

Step 1: Work out what you actually exported

You have…	It is	Serve it with
`index.html` + CSS/JS, no `package.json`	Plain static site	Any static file server
`package.json` with `vite`	Vite single-page app (typical Lovable/Bolt)	`npm run build`, then serve `dist/` with an SPA fallback
`package.json` with `next`	Next.js (typical v0)	Node server or Docker

Backend check: if the app uses Supabase (Lovable) or the builder's own auth/database, that part keeps talking to those services. Add your new domain to their allowed origins and redirect URLs before you switch DNS.

Step 2: Serve a Vite app with automatic HTTPS

On any Ubuntu server with your domain's A record pointing at it:

sudo apt install -y caddy
npm ci && npm run build
sudo mkdir -p /var/www/app && sudo cp -r dist/* /var/www/app/

/etc/caddy/Caddyfile:

app.example.com {
    root * /var/www/app
    encode zstd gzip
    try_files {path} /index.html
    file_server
    header /assets/* Cache-Control "public, max-age=31536000, immutable"
    header /index.html Cache-Control "no-cache"
}

sudo systemctl reload caddy

Caddy fetches a Let's Encrypt certificate on the first request. The try_files … /index.html line is the important one: it's what stops /dashboard from 404-ing when someone refreshes.

Step 3: Next.js exports

Set output: "standalone" in next.config.js, then use the multi-stage Dockerfile in the repo:

docker build -t myapp .
docker run -d --restart unless-stopped -p 127.0.0.1:3000:3000 --env-file .env myapp

…and reverse-proxy to it:

app.example.com {
    reverse_proxy 127.0.0.1:3000
}

Step 4: Deploy on every push

The repo includes a GitHub Actions workflow that builds the app (if there's a package.json) and rsyncs it to your server. Add DEPLOY_HOST, DEPLOY_USER and DEPLOY_SSH_KEY as secrets and you're done.

The five problems you'll probably hit

Blank page → the build used a sub-path. Set base: '/' in vite.config.
404 on refresh → missing SPA fallback (see Step 2).
Env vars missing → Vite only exposes VITE_* vars, baked in at build time. Rebuild after changing them.
Login redirect fails → add the new domain to your auth provider's redirect URLs.
Mixed content → every API URL must be https://.

Where to run it

Any Linux VPS works — the configs aren't tied to a provider. If you want the shortcut: VeloxaHost servers start at $4/mo with snapshots, and Veloxa Build hosts what it builds on every plan.

Disclosure: we build VeloxaHost and Veloxa Build. The repo is MIT-licensed and provider-neutral — PRs welcome.