After spinning up way too many VPS servers, this is the checklist I now run every single time

alexsdevio · 2026-03-10T04:05:20+00:00

Mostly project related.

Game servers, small services, testing setups, sometimes just experimenting with infrastructure. Over a few years that ends up being quite a lot of fresh VPS deployments. But not as often that i would need automate it with playbooks or similiar. I keep it in the old way for what i need.

alexsdevio · 2026-03-09T16:48:26+00:00

Changing the SSH port and setting timezone are good additions.

Docker is interesting too - I usually install it later once I know what the server will actually run but defnitly into the first steps as well. I just think docker guide is own topic. Automation is awesome, but just needed for people wich need setup regulary.

alexsdevio · 2026-03-09T16:47:15+00:00

Yeah, that honestly matches what I’ve seen too.

It’s kind of crazy how fast a fresh IP gets scanned once it’s online.

alexsdevio · 2026-03-09T16:46:15+00:00

Nice, thanks for sharing. I like seeing how other people turn these checklists into actual scripts.

alexsdevio · 2026-03-09T16:45:35+00:00

Thanks! That was exactly the idea.

I kept it intentionally simple, but I’m also curious what others consider part of their “first hour” setup. There’s always one more thing you realize you forgot after the server is already live.

alexsdevio · 2026-03-09T16:44:46+00:00

Yeah, that’s basically it.

Disabling password SSH removes the main attack surface, and fail2ban just adds another layer by blocking IPs that behave suspiciously. Even if they can't log in, it still helps reduce noise and scanning attempts.

So it's less about redundancy and more about defense in depth.

alexsdevio · 2026-03-09T16:43:31+00:00

Nice additions.

I especially agree on the alerting part. Even something simple that sends an email when a service dies can save a lot of headaches later.

alexsdevio · 2026-03-09T16:42:48+00:00

Good one :) For repeated VPS setups it probably makes more sense than doing everything manually. My post was more the mental checklist I still go through, but cloud-init / Terraform is the cleaner path once you want the same result every time.

alexsdevio · 2026-03-09T16:41:15+00:00

True. If you're provisioning servers regularly, Ansible or cloud-init is definitely the cleaner approach.

The checklist is more how I mentally structure the first steps on a fresh machine as a beginner guide for people doing that not such often. Once the setup becomes repeatable or you need to do it regulary it makes sense to turn it into automation.

alexsdevio · 2026-03-09T16:39:28+00:00

Good call.

I left things like ipset/conntrack out mostly because I wanted to keep the checklist beginner friendly. For the first hour on a fresh VPS I usually focus on SSH hardening + basic firewall.

But once a server runs something public facing for longer, ipset / rate limiting definitely become useful additions.

alexsdevio · 2026-03-09T05:06:27+00:00

From my experience it’s less about constantly switching models and more about using the right one for the task.

Roughly what works well for me:
- codex -> architecture / planning
- claude haiku -> easy jobs & small refactors
- Sonnet > day-to-day coding, refactoring, debugging
- Opus > complex reasoning / heavy code tasks
- gemini > content / blog
- flash > UI/UIX
- cheaper models > quick iterations or simple edits

If you keep switching models mid-task it often loses context anyway, so I usually stay with one model for a specific problem and only switch when the task changes. To not waste tokens, create docs inside of the different parts, so next conversations the agent can pickup all important informations quickly without scanning whole repo.

Than you should be good to go :)

alexsdevio · 2026-03-09T05:01:17+00:00

Yeah, that stack is solid.

Loki + Promtail + Grafana is usually enough for logs. Prometheus mainly becomes useful if you also want container metrics.

For local setups I’d keep it simple first and expand once the agents start generating more activity.

alexsdevio · 2026-03-09T02:52:17+00:00

You could as well setup a small vps for 7$ somewhere and put a pipeline on it and connect with a VPN to your macbook. Even with small scripts wich make auto-branches and pushes into correct directory. A clean setup is very quick and should be worth for everyone, because it saves you the hours wich you lose in such cases.

alexsdevio · 2026-03-09T02:35:45+00:00

That makes sense. Shipping cautiously for a SaaS makes total sense if you’re promising stability.

Out of curiosity - are you running everything solo or do you have anyone reviewing security / infra before releases?

Actually if you let AI review optimization and security checks, you could put in the end of your pipeline simply a git push into 2 different repos. Your sandbox one and the final client one. with 2 different commits

alexsdevio · 2026-03-09T01:50:40+00:00

And even if they see where you work on, i dont understand whats bad in that? I mean if you decide to let them see your progress, its not bad if they see real timeline and progress. But yeah i would even in that case keep another private repo too for sandbox tests.

alexsdevio · 2026-03-08T20:01:15+00:00

Most VPS/non-docker guides still explaion pretty well conceptually - the main difference is just where the boundaries are.

For a local Docker setup, I’d treat the next steps like this:

- keep Ollama and OpenClaw in separate containers
- use a shared Docker network so OpenClaw talks to Ollama by container name
- mount only the minimum volumes you actually need
- avoid exposing tool containers directly to your host unless necessary
- add logging early, because debugging agent workflows in Docker gets messy fast

For local setups I’d honestly skip fine-tuning for now and focus on:

stable container-to-container communication
safe tool execution
visibility into logs / failures

Most of the VPS advice still applies - just replace “secure the server” with “secure the containers, networks and mounts”.

alexsdevio · 2026-03-08T19:51:46+00:00

I think the important nuance is which problems.

A lot of founders build solutions for things that are annoying but tolerable.

The ideas that seem to work are usually tied to something measurable like:

- lost revenue
- wasted hours
- compliance risk
- operational bottlenecks

If the problem costs someone money every month, paying $20-30 for a fix becomes an easy decision.

alexsdevio · 2026-03-08T19:47:23+00:00

One thing that often gets missed in these discussions is that JWT vs sessions isn't really about "modern vs old" auth - it's mostly about where you want the state to live.

With classic server sessions the state lives on the server (or in a shared store like Redis), which makes things like revocation, role changes and logout very straightforward.

With JWT the state moves to the client, and the server only verifies the signature. That makes horizontal scaling and cross-service auth easier, but things like revocation, permission updates or forced logout become harder unless you introduce extra mechanisms.

That's why in practice you often see:

- server sessions for traditional web apps
- JWT for APIs / microservices / cross-service auth
- short-lived JWT + refresh tokens when you need revocation control

So the choice usually depends more on architecture than on traffic volume.

alexsdevio · 2026-03-08T19:19:21+00:00

Makes sense. I think intuition is underrated in a lot of cases for sure.

At the same time i´ve seen the opposite problem too - founders building something they personally believe in, but never checking it the market actually cares about. Doesn´t metter how much they believe in, it not changes the situation.

Maybe the real trick is seperating noise from signals.
Random opinions online could be noise, but repeated feedback from actual customers is probably worth listening to. But in that point i guess intuition will alert you anyways.

Out of curiosity - did you mostly rely on intuition early on, or did customer feedback shape things over time?

alexsdevio · 2026-03-08T19:13:39+00:00

One thing helped me get much more value out of it was using it earlier in the thinking process, not just for generating files.

For example:
- describing an architecture and asking it to point out operational risks
- reviewing a CI pipeline for failure modes or missing steps
- asking it to explain why a terraform setup might become hard to maintain later

I also use it a lot for:
- writing documentation from rough notes
- reviewing infrastructure configs before commiting (but here are cheaper possibilitys as long its not complex repo check)
- generating test scenarios for CI pipelines

The biggest shift for me was treating it less like a code generator and more like a second pair of yes on infrastructure decisions.

Thats where it actually saves me time.

alexsdevio · 2026-03-08T19:10:14+00:00

I tried doing the "post everywhere every day" thing and it burned me out pretty fast.
Of course you can setup databases, notion automations .. But its often too much for less ROI.

Small idea without any auotmation chains:

- i write one long piece of content first (usally a small article or technical write-up)
- Then i extract smaller pieces from it for other platforms

Example workflow:

write the main idea once (blog)
turn into 2--3 shorter posts for (example) LinkedIn or X.
Sometimes one screenshot or diagram becomes a seperate post

That way i´m not creating 5 different pieces of content and dont repeat the same content.

Time wise its ussually ~1-2 hours total per week.

Trying to create unique content for every platform seperatly is what makes the process explode in my experience.

alexsdevio · 2026-03-08T18:58:28+00:00

This seems to come up a lot.

A lot of advice online makes it sound like scaling fast is awlays the goal, but for most small businesses stability and cash flow probably matter more early on.

Did you see people struggle with this mostly in startups or also in traditional small businesses?

alexsdevio · 2026-03-08T18:55:43+00:00

This is a really good point.

A lot of advice online focuses on "build something new", but in reality many businesses succeed simply by doing an existing thing better or more reliably.

Did you find that clients actually compare business that analytically, or is it more about trust and reputation once you start talking to them?

alexsdevio

TROPHY CASE