DEV Community: Wade Thomas

Ansible Installation and Configuration on Ubuntu — Automate Your Server Management

Wade Thomas — Fri, 10 Jul 2026 04:17:07 +0000

Introduction

What is Ansible?

Ansible is an automation language that can describe any IT environment, whether homelab or large-scale infrastructure. It is easy to learn and reads like clear documentation.

If you manage multiple servers and find yourself doing the same configuration over and over — setting up SSH keys, disabling root users, configuring firewalls — Ansible can automate the entire process and dramatically increase your productivity.

It only requires Ansible on the Control Node and Python 3 on the Managed Node.

What is the Control Node?

The system that Ansible is installed on — it controls the remote machines.

What is the Managed Node?

The remote system or host that Ansible controls. Ansible is agentless, meaning you don't need to install Ansible on managed nodes — just Python 3.

Installing Ansible on Ubuntu (Control Node)

sudo apt update
sudo apt install software-properties-common
sudo add-apt-repository --yes --update ppa:ansible/ansible
sudo apt install ansible

Note: Ensure Python 3 is installed on your remote server. Ubuntu 24.04 LTS ships with Python 3 by default.

Create the Inventory Folder and Hosts File

The hosts file maps the remote machines you want to control.

Folder structure:

Ansible/
├── inventory/
│ └── hosts
└── playbooks/
└── apt-update.yml

inventory/hosts

[servers]
vpsServer ansible_host=10.10.100.45
work-ToRule
10.10.45.62

You can give hosts an alias by pairing a name with an IP address. In the example above, vpsServer is an alias for 10.10.100.45.

Your First Playbook — Update Ubuntu and Set Timezone

Create playbooks/apt-update.yml:

- hosts: '*'
  become: true
  serial: 1
  tasks:
    - name: Set system timezone to Trinidad and Tobago time
      community.general.timezone:
        name: America/Port_of_Spain

    - name: Update apt cache
      apt:
        update_cache: yes
        cache_valid_time: 3600

    - name: Upgrade all packages to the latest version
      apt:
        upgrade: dist

    - name: Check if reboot is required
      stat:
        path: /var/run/reboot-required
      register: reboot_required_file

    - name: Reboot the server
      reboot:
        msg: 'Reboot initiated by Ansible due to package upgrades'
        connect_timeout: 5
        reboot_timeout: 300
        pre_reboot_delay: 0
        post_reboot_delay: 30
      when: reboot_required_file.stat.exists

Breaking Down the Playbook

Key	Description
`hosts: '*'`	Target all hosts in inventory. Use an alias, DNS name, or IP to target a single host.
`become: true`	Grants Ansible sudo privileges.
`serial: 1`	Processes servers one at a time instead of all at once.
`tasks`	A list of individual actions to run on the target hosts.

Each task has four parts:

name — a plain-text description of what the task does
Collection (community.general) — the Ansible content bundle the module belongs to
Module (timezone, apt, reboot) — the tool that executes the action
Parameters (name: America/Port_of_Spain) — the specific options passed to the module

📚 Browse all available modules and collections at docs.ansible.com

Running the Playbook

Step 1 — Test connectivity with a ping

ANSIBLE_HOST_KEY_CHECKING=FALSE ansible -i ./inventory/hosts vpsServer -m ping --user root --ask-pass

Flag	Description
`ANSIBLE_HOST_KEY_CHECKING=FALSE`	Skips SSH host key verification — useful for fresh servers
`-i ./inventory/hosts`	Points to your inventory file
`vpsServer`	The target host alias
`-m ping`	Runs the ping module to check connectivity and Python availability
`--ask-pass`	Prompts for SSH password

Once you get a green pong response, you're ready to run the playbook.

Step 2 — Run the playbook

ansible-playbook ./playbooks/apt-update.yml --user root -e "ansible_port=22" --ask-pass --ask-become-pass -i ./inventory/hosts

Flag	Description
`ansible-playbook`	Runs a full automation script instead of a single ad-hoc task
`./playbooks/apt-update.yml`	Path to your playbook file
`--user root`	SSH connection username
`-e "ansible_port=22"`	Injects extra variable to force port 22
`--ask-pass`	Prompts for SSH login password
`--ask-become-pass`	Prompts for sudo password (redundant when logging in as root)
`-i ./inventory/hosts`	Points to your inventory file

Execution Flow

Ansible reads ./inventory/hosts to find the target server's IP
Prompts for SSH password
Prompts for sudo password
Connects to port 22 as root
Opens apt-update.yml and executes each task in order

Conclusion

A big shout-out to Aldo @aldo_cve for recommending Ansible in a previous post — it's been a great addition to my server management workflow.

I hope you found this walkthrough useful. Stay tuned for more posts where I share playbooks I find useful in my day-to-day infrastructure work.

Looking for developer templates built on TanStack, Directus, and Tailwind CSS? Check out my store 👇
🛒 northernrangedigital.lemonsqueezy.com

How to Secure a VPS: The Complete Ubuntu Hardening Guide

Wade Thomas — Thu, 02 Jul 2026 05:26:20 +0000

The moment a VPS gets a public IP, it's already being scanned. Automated bots start hammering the default root account with password guesses within minutes of the server going online — before you've even finished your first apt update.

This guide walks through the baseline hardening I run on every fresh Ubuntu server before deploying anything to it: creating a proper user account, locking down root, setting up a firewall, quieting bot noise on SSH, and auto-banning repeat offenders.

Prefer to follow along on video?

1. Stop Using the Root User

Every Linux server in the world ships with an account named root. That's the problem — hackers already know the username, so they only need to guess the password or find one exploit to get full control. A custom username forces an attacker to guess two unknowns instead of one.

A few other reasons to move off root:

No safety net. Root executes destructive commands instantly, no confirmation. Run rm -rf / as root and it's gone. A standard user needs sudo, which at least forces a pause and a password prompt.
Bots target root specifically. The moment a VPS goes online, automated bots start brute-forcing the root account with thousands of password guesses per minute. Disable root login and that entire attack surface disappears.
No accountability. If more than one person has server access, a shared root login makes it impossible to tell who did what. Individual sudo accounts get logged to /var/log/auth.log, so every command is tied to a specific user.

Create a sudo user

adduser your_username
usermod -aG sudo your_username

-aG breaks down into two flags: -G adds the user to the group that follows (sudo), and -a (append) makes sure the user is added to that group rather than having all their other group memberships wiped out. Together, -aG says: add this user to sudo, keep everything else as-is.

Verify it worked:

groups your_username

Lock down root

Log out of root and back in as your new sudo user first, then:

# Lock the root password
sudo passwd -l root

# Disable root login over SSH
sudo nano /etc/ssh/sshd_config
# set: PermitRootLogin no
sudo systemctl restart sshd

# Confirm root is locked
sudo passwd -S root

2. Set Up a Firewall (UFW)

A firewall closes off everything you're not explicitly using. On a fresh VPS, that means:

Blocking brute-force attempts on ports you don't need exposed
Keeping internal-only services (databases, admin tools) off the public internet
Restricting sensitive ports like SSH to specific IPs, if needed
Dropping unexpected traffic, which softens basic DoS attempts
Closing the door on any hidden vulnerability in something you're running

Ubuntu ships with UFW (Uncomplicated Firewall), which blocks all incoming traffic by default and only opens what you explicitly allow:

# Allow SSH first so you don't lock yourself out
sudo ufw allow OpenSSH
# or: sudo ufw allow 22/tcp

# Allow web traffic if you're hosting a site
sudo ufw allow http
sudo ufw allow https

# Turn it on
sudo ufw enable

# Check status
sudo ufw status verbose

3. Change the Default SSH Port

Within minutes of going live, bots start hammering port 22 — not targeted attacks, just scripts sweeping the internet for the default SSH port. Moving to something non-standard, like 2222, makes those scanners skip right past you.

sudo nano /etc/ssh/sshd_config
# uncomment #Port 22 and change it:
# Port 2222

sudo ufw allow 2222/tcp
sudo ufw reload
sudo systemctl restart sshd

Worth being honest about this one: security researchers call this "security through obscurity," and on its own it's a weak measure — it doesn't make the server harder to break into. What it does do is keep your auth logs from being flooded with bot noise, which makes real suspicious activity much easier to spot. Pair it with SSH keys, disabled password auth, and Fail2Ban for actual hardening.

4. Install Fail2Ban

Fail2Ban watches your logs for repeated failed login attempts and temporarily bans the offending IP at the firewall level.

Why it's worth running:

Free, open-source, and quick to set up
Highly configurable — ban duration, whitelisted IPs, which services to watch
Bans happen at the firewall, so malicious traffic doesn't eat server resources
Can integrate with notifications for real-time alerts

Where it falls short:

Reactive, not preventive — it only acts after a set number of failed attempts have already happened
Can lock out legitimate users who fat-finger a password a few times in a row
Weak against distributed attacks, since it bans by IP and botnets rotate through thousands of them
Vulnerable to IP spoofing
Can conflict with Docker's iptables rules on a Docker host, causing bans to fail or hit the wrong container

Install it:

sudo apt update
sudo apt install fail2ban -y
sudo systemctl start fail2ban
sudo systemctl enable fail2ban

(The -y flag auto-confirms every prompt during install — only use it once you're already certain about the package.)

Wrap-Up

None of these steps make a server unbreakable on their own — a sudo user, a firewall, an obscure SSH port, and Fail2Ban are each individually beatable. Stacked together, they cut off the low-effort, automated attacks that hit every public IP within minutes of going live, and they keep your logs clean enough that you'd actually notice something that isn't normal.

If you found this useful, the video above walks through each step live. Let me know in the comments if you run into anything setting this up on your own box.

What is Redis? The In-Memory Data Store That Makes Your App Faster

Wade Thomas — Wed, 10 Jun 2026 03:44:49 +0000

🎬 This article is a companion to my YouTube video. Watch it here:

Introduction

In this video we are going to talk about Redis — what it is, what it does, and why it is an important part of my back-end stack.

What is Redis?

Redis is a free, open-source, in-memory data store. Unlike PostgreSQL which stores data on disk, Redis stores data entirely in memory — in RAM. This makes it extremely fast. Redis can handle millions of operations per second with sub-millisecond response times.
Redis is most commonly used as a cache, a session store, a message broker, and a real-time data store.

What is Caching?

When your application queries a database, that query takes time — it reads from disk, processes the query, and returns the result. If the same query is made thousands of times per second, you are hitting the database thousands of times unnecessarily.
Caching solves this by storing the result of a query in memory. The first request hits the database and the result is stored in Redis. Every subsequent request gets the result from Redis — which is in memory and therefore much faster — instead of hitting the database again.
Think of it like a shortcut. Instead of driving the long route to the database every time, you take the shortcut through Redis.

What Does Redis Do?

Caching

Store frequently accessed data in memory for fast retrieval. Database query results, API responses, computed values — anything that is expensive to compute and accessed frequently is a good candidate for caching.

Session Storage

Store user session data in Redis instead of the database. Since sessions are read on every request, having them in memory is significantly faster than a database lookup.

Rate Limiting

Track how many requests a user or IP address has made in a given time window. Redis's atomic increment operations make it perfect for implementing rate limiting.
Message Queues and Pub/Sub
Redis supports publish/subscribe messaging and message queues. Applications can publish messages to a channel and subscribers receive them in real time.

Leaderboards and Counters

Redis sorted sets make it trivial to implement leaderboards, counters, and real-time analytics.

Why Directus Uses Redis

Directus uses Redis for two primary purposes.
First, as a cache layer. Directus caches API responses, schema information, and permission lookups in Redis. This dramatically reduces database load and speeds up API response times.
Second, for synchronization across multiple Directus instances. If you run multiple instances of Directus for high availability or horizontal scaling, Redis acts as the shared cache and message bus that keeps them in sync.
For a single Directus instance Redis is optional but recommended. For multiple instances it is required.

Why I Chose Redis

Redis is the industry standard for caching and session storage. It is fast, reliable, widely supported, and Directus has first-class support for it. Adding Redis to the stack costs very little in terms of resources but provides significant performance benefits as the application scales.

Conclusion

Redis is a powerful in-memory data store that makes your application faster and more scalable by caching frequently accessed data and handling real-time workloads. It is a small but important piece of a production-ready back-end stack.
In an upcoming video we will deploy Redis alongside Directus and PostgreSQL on our VPS using Coolify.

References

Redis Website
Redis Documentation
Redis GitHub

🔔 Subscribe to my YouTube channel for the full series on building a modern web app back end from scratch.

What is PostgreSQL? The Database That Powers Modern Web Applications

Wade Thomas — Tue, 26 May 2026 15:28:23 +0000

🎬 This article is a companion to my YouTube video. Watch it here:

Introduction

In this video we are going to talk about PostgreSQL — what it is, why it is one of the most popular databases in the world, and why it is the database I use to power my web applications.

What is PostgreSQL?

PostgreSQL — often called Postgres — is a free, open-source relational database management system. It has been in active development for over 35 years and is widely considered one of the most advanced, stable and feature-rich databases available.
A relational database stores data in tables — rows and columns — and uses SQL to query and manipulate that data. If you have ever worked with a spreadsheet, you already understand the basic concept.

Why PostgreSQL?

ACID compliance

PostgreSQL is fully ACID compliant — Atomicity, Consistency, Isolation, Durability. Transactions either complete fully or not at all. If something goes wrong mid-transaction, the database rolls back to the previous state. For financial data, orders, user accounts — anything where data integrity matters — this is critical.

Advanced data types

PostgreSQL supports JSON and JSONB for document storage, arrays, UUID, geometric types, full-text search and more. You get the flexibility of a document database with the reliability of a relational database.
Excellent performance
PostgreSQL handles complex queries, large datasets and high concurrency extremely well. It has a sophisticated query planner and optimizer that makes even complex joins and aggregations fast.

Extensibility

PostgreSQL is highly extensible. PostGIS for geospatial data, pgvector for AI embeddings, and TimescaleDB for time series data are just a few examples of powerful extensions available.
Open source and free
PostgreSQL is completely free and open source with no licensing costs. There is no enterprise tier required to access advanced features.

Widely supported

Almost every major framework, ORM, and tool supports PostgreSQL. Directus, Prisma, Drizzle, Sequelize, Django, Rails — they all work with PostgreSQL out of the box.

PostgreSQL vs MySQL

PostgreSQL is more standards compliant and supports more advanced features out of the box. MySQL is slightly simpler to set up and has historically been faster for simple read-heavy workloads. For modern web applications with complex data requirements, PostgreSQL is generally the better choice.

Why I Chose PostgreSQL

PostgreSQL is the database that Directus recommends and works best with. It gives me full ACID compliance, advanced data types, and excellent performance — everything I need for production web applications.

Conclusion

PostgreSQL is a battle-tested, feature-rich, open-source relational database that powers some of the world's largest applications. For modern web development it is one of the safest and most capable choices available.
In an upcoming video we will deploy PostgreSQL alongside Directus on our VPS using Coolify.

References

• PostgreSQL Website
• PostgreSQL Documentation

🔔 Subscribe to my YouTube channel for the full series on building a modern web app back end from scratch.

What is Directus? The Headless CMS That Sits On Your Own Database

Wade Thomas — Sun, 17 May 2026 22:17:59 +0000

🎬 This article is a companion to my YouTube video. Watch it here:

Introduction

Before we get into setting up Coolify, I want to make sure you understand the tools we will be deploying. In this video we are going to talk about Directus — what it is, what it does, and why I chose it as the backbone of my back-end stack.

What is Directus?

Directus is a free, open-source, headless CMS and data platform. But before we go any further, let me explain what headless CMS means.

A traditional CMS — like WordPress — couples the content management system with the front end. The way your content is stored and the way it is displayed are tightly linked. You are locked into how WordPress presents your content.

A headless CMS separates the two. Directus manages and stores your data, and exposes it through a REST API or GraphQL endpoint. Your front end — whether it is a React app, a mobile app, or anything else — consumes that API and decides how to display the content. The CMS has no head — meaning no fixed front end — hence the name headless.

What Makes Directus Different?

It works with your existing database

Most headless CMS platforms use their own proprietary data storage. Directus sits on top of a standard relational database — PostgreSQL, MySQL, SQLite and more. Your data is stored in plain database tables that you own and can access directly. You are never locked into a proprietary format.

Auto-generated API

When you create a collection in Directus — think of a collection like a database table — it automatically generates a full REST API and GraphQL endpoint for that collection. No code required. You get full CRUD operations out of the box — create, read, update and delete.

Powerful admin dashboard

Directus comes with a beautiful, fully featured admin dashboard out of the box. Your clients or content editors can manage content without ever touching code. You can customize the dashboard with custom fields, relationships, file uploads, translations and more.

Role-based access control

Directus has a very granular permissions system. You can control exactly who can read, create, update or delete data at the collection level, the field level, and even the row level. This makes it suitable for multi-tenant applications and complex permission requirements.

File management

Directus includes a full file and asset management system. You can upload images, videos, documents and more. It supports on-the-fly image transformations — resize, crop, format conversion — all through URL parameters.

Flows — built-in automation

Directus has a built-in automation system called Flows. You can build workflows triggered by events — like sending an email when a new order is created, or updating a related record when a status changes — all without writing code.

Open source and self-hostable

Directus is completely open source. You can self-host it on your own server, which means your data stays on your infrastructure. There is also a cloud hosted option if you prefer a managed solution.

Why I Chose Directus

I chose Directus for several reasons.

First, it works with PostgreSQL out of the box. I wanted a standard relational database that I own and control, not a proprietary data store.

Second, the auto-generated API saves me an enormous amount of time. Instead of building CRUD endpoints for every collection, Directus handles that automatically. I focus on building features, not boilerplate API code.

Third, the admin dashboard is genuinely excellent. My clients can manage their own content without any technical knowledge. I do not have to build a custom admin interface for every project.

Fourth, it is self-hostable. My data stays on my server. I control the infrastructure, the costs, and the data.

What are the Limitations?

Not a traditional backend framework — complex business logic may require supplementing with custom code or choosing a different solution.
Licensing costs at scale — Directus is free and open source for projects generating up to $5 million USD in annual revenue. Beyond that threshold a commercial license is required. For the vast majority of startups, small teams and indie developers this limit will never be reached, making it effectively free for most use cases.
Can be overkill for simple projects — a basic blog may not need all of Directus's features.

Conclusion

Directus is a powerful, flexible, open-source headless CMS that sits on top of your own database and gives you a full API and admin dashboard out of the box. For developers building modern web applications who want to own their data and move fast without writing boilerplate, it is one of the best tools available.

In an upcoming video we will deploy Directus on our VPS using Coolify and connect it to our TanStack Start front end.

References

🔔 Subscribe to my YouTube channel for the full series on building a modern web app back end from scratch.

What is Coolify? Self-Hosting with Superpowers

Wade Thomas — Thu, 14 May 2026 03:40:29 +0000

🎬 This article is a companion to my YouTube video. Watch it here:

Introduction

In the last video, we talked about the VPS and why it is a compelling option for hosting your web applications. I mentioned a tool called Coolify that makes managing a VPS significantly easier. In this video, we are going to dive deeper into what Coolify actually is, what it does, and why I think it is one of the best tools available for developers and small teams who want the power of a VPS without the complexity of managing one from scratch.

What is Coolify?

Coolify is a free, open-source, self-hostable platform as a service — or PaaS. Think of it as your own personal Heroku or Render, but running on your own server. This means you own your infrastructure, your data, and your costs.

The best way to understand Coolify is to compare it to the alternatives. Platforms like Heroku, Render, and Railway are fully managed PaaS solutions. They abstract away all the server complexity — you push your code and it runs. The trade-off is cost and control. As your app scales, the bills grow quickly and you have limited control over the underlying infrastructure.

Coolify gives you the same developer experience — push your code and it deploys — but on a VPS that you control. You get the simplicity of a managed platform with the economics and control of a VPS.

What Does Coolify Do?

Coolify handles all the hard parts of running applications on a VPS.

Git Integration

Connect your GitHub, GitLab, or Bitbucket repository and Coolify will automatically deploy your app every time you push to your main branch. No manual deployments, no SSH commands — just push your code and it is live.

Dockerized Deployments

Every application Coolify deploys runs in a Docker container. This means your apps are isolated, portable, and consistent across environments. You do not need to know Docker deeply to use Coolify — it handles the containerization for you.

Automatic HTTPS

Coolify integrates with Let's Encrypt to automatically provision and renew SSL certificates for all your applications. Every app gets HTTPS out of the box with zero configuration on your part.

Built-in Reverse Proxy

Coolify uses Traefik as its built-in reverse proxy and web server. It automatically routes traffic to the right application based on the domain name. You can run multiple applications on the same VPS and Coolify handles the routing between them.

Database Management

Coolify can deploy and manage databases alongside your applications — PostgreSQL, MySQL, MongoDB, Redis and more. You can spin up a database with a few clicks and connect it to your application without any manual configuration.

Environment Variables

Manage your environment variables securely through the Coolify dashboard. No more manually editing .env files on the server.

Monitoring and Logs

Coolify provides basic monitoring and real-time log streaming for all your applications directly from the dashboard. You can see what your app is doing without SSH-ing into the server.

Backups

Coolify supports automated database backups to S3-compatible storage. Your data is protected without any manual backup scripts.

Why Would You Use Coolify?

You want the economics of a VPS without the complexity

A $6 to $10 per month VPS with Coolify can run multiple applications that would cost hundreds of dollars per month on Heroku, Render, or Railway. For a startup or indie developer this is a significant saving.

You want full control over your infrastructure

With Coolify you own everything. Your data stays on your server. You choose your hosting provider. You are not locked into any platform's pricing or terms of service.

You want a great developer experience

Coolify's dashboard is clean and intuitive. Deploying an application is genuinely just a few clicks. It does not feel like managing a server — it feels like using a modern PaaS.

You are running multiple projects

One VPS with Coolify can host multiple applications, multiple databases, and multiple domains. Instead of paying for separate hosting for each project, you consolidate everything onto one server.

What Are the Limitations?

You are responsible for your server — if your VPS goes down, your apps go down.
Some configuration is still required — especially for custom setups, firewalls, and advanced networking.
It is self-hosted — meaning you need to keep Coolify itself updated and maintained.
Not ideal for very large scale — for enterprise applications with massive traffic you may need dedicated infrastructure beyond a single VPS.

How Do You Get Started?

Getting Coolify up and running is surprisingly straightforward. In an upcoming video I will walk you through the complete setup — from provisioning a VPS to having Coolify installed and your first application deployed.

All you need to get started is:

A VPS with at least 2GB RAM and 2 CPU cores
A domain name
About 30 minutes of your time

Conclusion

Coolify bridges the gap between the simplicity of managed platforms and the power and economics of a VPS. For developers and small teams who want to own their infrastructure without being overwhelmed by server management, it is genuinely one of the best tools available right now.

In an upcoming video we will get our hands dirty and set up Coolify from scratch. See you there.

References

🔔 Subscribe to my YouTube channel for the full series on building a modern web app back end from scratch.

Back-End Web Development — VPS vs Vercel vs Netlify

Wade Thomas — Tue, 12 May 2026 01:14:25 +0000

🎬 This article is a companion to my YouTube video. Watch it here:

Introduction

Every great web application with millions of users has an even greater back end — and it has to be. Accessing your app over a prolonged period of time will test the integrity, availability, and speed of your back end. Backend technology can be inexpensive, or it can cost you thousands of dollars. So what's the deal here?

Let me warn you that this channel is highly opinionated. I am sharing the tools that I use and how I use them.

For my back end that powers my web apps, I use Directus for my headless CMS, supported by a PostgreSQL and Redis database, hosted on a VPS, and managed by Coolify. Wow, that is a mouthful — and in this series we will explore how they all work together.

So let's tackle each technology one at a time, starting with the VPS.

What is a VPS?

A Virtual Private Server, known as a VPS, is a virtual environment created on a physical server. Think of it like an apartment building — everyone shares the same physical structure, but each unit has its own private space, utilities, and security.

While multiple VPS instances share a physical server, be careful not to confuse this with shared hosting. Each VPS is allocated its own dedicated resources, which are restricted to that VPS for as long as it is active. Therefore, the performance of a VPS is not directly affected by the usage of other VPS instances, but rather by the underlying performance of the physical server itself.

What are the Benefits of a VPS?

There are several benefits to consider when deciding on virtual private server hosting:

Greater control — Compared to shared hosting, you have root access and can fully customize your server environment.
Dedicated resources — Allocated CPU, memory, and storage help ensure consistent performance.
Scalability — You can easily scale resources up or down to accommodate changing traffic and application demands.
Cost-effectiveness — A VPS typically offers a balance between the affordability of shared hosting and the power of a dedicated server.
Improved security — Isolation from other users on the same physical server enhances security.
Choice of operating system — You can choose the operating system that best suits your needs, such as Linux or Windows.

How Does it Stack Up Against Vercel or Netlify?

Vercel

Vercel offers minimal setup with Git integration and fast deployment right out of the box. It has a free Hobby plan, but it is strictly for personal, non-commercial use. Once your app grows and needs to scale, you will need to move to a paid plan.

The Pro plan starts at $20 per user per month, and also covers serverless functions. Despite the name, serverless code still runs on a physical server — however, the infrastructure management, such as scaling, security patching, and provisioning, is handled entirely by the cloud provider.

The main factor to watch carefully is cost. Vercel uses usage-based billing, and costs can escalate quickly — especially since Turbo build machines became the default for new Pro projects in February 2026, at $0.126 per build minute. A moderate team workflow can generate over $400 per month in build costs alone, before bandwidth and compute charges. I have seen some alarming Vercel bills shared online by customers, which means you need to fully understand the pricing model before you commit.

Netlify

Netlify has historically been more suited to static sites and composable web applications. Composable applications are software systems built from independent, interchangeable modules rather than a single rigid codebase. Netlify also has Git integration, customizable build plugins, and serverless functions.

Netlify moved to a credit-based pricing model in September 2025, designed to simplify metered billing. As of April 2026, the Pro plan costs $20 per month and now includes unlimited team member seats, which is an improvement over the previous per-seat model. However, teams working on active projects with real traffic can burn through their credit allocation quickly, and credit pack add-ons at $10 per 1,500 credits mean teams can regularly spend $40 to $80 or more per month beyond the base subscription. Your overall control is also more limited compared to a VPS, and you will still face a monthly cost as your app grows.

The VPS

VPS prices can grow as your app grows, but in my experience at a slower and more predictable rate — with no surprise charges. However, if you manage a VPS yourself, it requires understanding web servers, firewalls, operating systems, caching, and more. It can get complex very quickly and may cause you to spend more time managing the server than building and scaling your app.

That is why some developers and business owners hire a team to handle it. Small teams may not have the budget for a dedicated infrastructure team, so they often opt for a more convenient managed solution.

Coolify — The Game Changer

There is one tool that I think is worth mentioning and is a genuine game changer — and that is Coolify.

Coolify is a self-hostable platform that makes managing your VPS significantly easier. It offers:

✅ Git integration
✅ Dockerized container deployments
✅ Automatic HTTPS
✅ Built-in web server with no manual configuration required

This makes the VPS a very real and competitive option worth considering. If you choose a solid hosting provider and pair it with the right tools, you can make this an absolute dream to work with.

Now don't get me wrong — even with Coolify there are some configurations you will have to make. But I do believe a VPS is a great solution for a startup, mid-size, or enterprise scaled app with the right tools.

Conclusion

Stay with me in this series and we will definitely explore the possibilities. See you in the next video.

References

🔔 Subscribe to my YouTube channel for the full series on building a modern web app back end from scratch.

Protecting Routes in TanStack Start with Zustand

Wade Thomas — Mon, 30 Mar 2026 04:54:07 +0000

Route protection in TanStack Start doesn't have a built-in auth guard out of the box, but combining a Zustand store with a layout route gives you a clean, reusable solution that works well with SSR and hydration.

Here's the full setup.

The Auth Store

First, the Zustand store. It persists the user to localStorage via the persist middleware and uses a hasHydrated flag to track when the store has been rehydrated from storage. This is critical — without it you'll get a flash of redirect on page load even for logged-in users.

import type { User } from '@/types';
import { create } from 'zustand';
import { persist } from 'zustand/middleware';
import { logoutUser } from '@/lib/directus';

interface AuthState {
  user: User | null;
  hasHydrated: boolean;
  setHasHydrated: (state: boolean) => void;
  setUser: (user: User) => void;
  logout: () => Promise<void>;
  isLoggedIn: () => boolean;
}

export const useAuthStore = create<AuthState>()(
  persist(
    (set, get) => ({
      user: null,
      hasHydrated: false,
      setHasHydrated: (state) => set({ hasHydrated: state }),
      setUser: (user) => set({ user }),
      logout: async () => {
        await logoutUser();
        set({ user: null });
      },
      isLoggedIn: () => !!get().user,
    }),
    {
      name: 'auth-storage',
      onRehydrateStorage: () => (state) => {
        state?.setHasHydrated(true);
      },
    },
  ),
);

The onRehydrateStorage callback fires once Zustand has finished reading from localStorage and sets hasHydrated to true. This is the signal your protected layout waits for before making any redirect decisions.

The User Type

The User type maps directly to the Directus user fields you need in your app.

export interface User {
  id: string;
  first_name: string;
  last_name: string;
  email: string;
  avatar: string | null;
  location?: string;
  description?: string;
}

The Protected Layout Route

TanStack Start's file-based routing lets you create layout routes that wrap child routes. The _protectedLayout route acts as an auth guard — it checks the store and redirects to login if no user is present.

import MainLayout from '@/components/layouts/MainLayout';
import { createFileRoute, useNavigate } from '@tanstack/react-router';
import { useAuthStore } from '@/store/authStore';
import { useEffect } from 'react';

export const Route = createFileRoute('/auth/_protectedLayout')({
  component: ProtectedLayout,
  notFoundComponent: () => {
    return <p>This page doesn't exist!</p>;
  },
});

function ProtectedLayout() {
  const { user, hasHydrated } = useAuthStore();
  const navigate = useNavigate();

  useEffect(() => {
    if (hasHydrated && !user) {
      navigate({ to: '/auth/login' });
    }
  }, [user, hasHydrated]);

  if (!hasHydrated) return null;
  if (!user) return null;

  return <MainLayout />;
}

The two guard conditions are important:

if (!hasHydrated) return null — waits for the store to rehydrate before rendering anything, preventing a flash of redirect
if (!user) return null — prevents rendering the layout while the redirect is in flight

Only when both conditions pass does MainLayout render.

The Main Layout

MainLayout is a standard shell component that renders your header, footer and the current route's content via Outlet.

import { Outlet } from '@tanstack/react-router';
import Header from '../Header';
import { Footer } from '../Footer';

export default function MainLayout() {
  return (
    <div>
      <Header />
      <div className="max-w-7xl mx-auto p-4">
        <Outlet />
      </div>
      <Footer />
    </div>
  );
}

Any route nested under _protectedLayout automatically gets the auth guard and the shared layout — no need to add protection logic to individual routes.

How It All Fits Together

User logs in → setUser is called → Zustand persists the user to localStorage
User revisits the app → Zustand rehydrates from localStorage → hasHydrated is set to true
Protected layout checks hasHydrated and user → renders MainLayout if both pass
User logs out → logout calls Directus, clears the user from the store → redirect to login

This pattern keeps auth logic in one place, works cleanly with SSR hydration, and scales to as many protected routes as you need without repeating any guard logic.

Have questions about the setup? Drop a comment below.

Directus Auth out of the Box — Registration, Login, Email Verification and Password Reset

Wade Thomas — Mon, 30 Mar 2026 04:37:13 +0000

One of the things I appreciate most about Directus is that authentication is built in. Registration, login, email verification, and password reset — all handled without reaching for a third party auth service like Auth0 or Clerk.

Here's how I implement the full auth flow in a TanStack Start app using the Directus SDK.

User Registration

The SDK's registerUser function handles registration. You pass the email, password and any additional fields. The verification_url tells Directus where to redirect the user after they click the link in their email — Directus appends the token to that URL automatically.

export async function registerUser(
  email: string,
  password: string,
  firstName: string,
  lastName: string,
) {
  const options = {
    first_name: firstName,
    last_name: lastName,
    verification_url: `${import.meta.env.VITE_TANSTACK_URL}/auth/verify-email`,
  };
  return await directus.request(
    registerUserDirectus(email, password, options),
  );
}

Directus sends the verification email automatically via your configured SMTP provider. I use Resend — SMTP is configured directly in the Docker Compose file via environment variables and the whole setup takes just a few minutes.

EMAIL_TRANSPORT: smtp
EMAIL_SMTP_HOST: smtp.resend.com
EMAIL_SMTP_PORT: 465
EMAIL_SMTP_USER: resend
EMAIL_SMTP_PASSWORD: your_resend_api_key
EMAIL_FROM: noreply@yourdomain.com

Login

Logging in is a single call on the Directus client. Session cookies are handled automatically thanks to the credentials: 'include' config set up on the client.

export async function loginUser(email: string, password: string) {
  return await directus.login({ email, password });
}

Clean, no token management, no localStorage juggling. The session is maintained via cookie.

Email Verification

When the user clicks the link in their verification email, they land on your /auth/verify-email route with a token in the query string. You take that token and hit Directus's verify endpoint directly.

function VerifyEmailComponent() {
  const { token } = Route.useSearch();
  const [status, setStatus] = useState<
    'verifying' | 'success' | 'error' | 'pending'
  >('pending');

  useEffect(() => {
    if (!token) return;

    async function verify() {
      setStatus('verifying');
      try {
        const response = await fetch(
          `${import.meta.env.VITE_DIRECTUS_URL}/users/register/verify-email?token=${token}`,
          { method: 'GET' },
        );
        if (response.ok) {
          setStatus('success');
        } else {
          setStatus('error');
        }
      } catch (err) {
        setStatus('error');
      }
    }
    verify();
  }, [token]);
}

The status state drives your UI — show a spinner while verifying, a success message on completion, or an error state if the token is invalid or expired.

Password Reset

The password reset flow works the same way — Directus emails the user a reset link with a token, they land on your reset page, and you POST the new password along with the token to Directus's reset endpoint.

const handleSubmit = async (e: React.FormEvent) => {
  e.preventDefault();
  if (password !== confirm) {
    setError('Passwords do not match.');
    return;
  }
  setLoading(true);
  setError(null);

  try {
    const response = await fetch(
      `${import.meta.env.VITE_DIRECTUS_URL}/auth/password/reset`,
      {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ token, password }),
      },
    );

    if (response.ok || response.status === 204) {
      navigate({ to: '/auth/login' });
    } else {
      setError('Failed to reset password. The link may have expired.');
    }
  } catch {
    setError('Something went wrong. Please try again.');
  } finally {
    setLoading(false);
  }
};

A 204 response means success — redirect the user to login. Handle expired tokens gracefully with a clear error message.

What Directus Handles For You

✅ Sending the verification email — via your SMTP provider configured in Docker Compose
✅ Generating and validating tokens
✅ Sending the password reset email
✅ Session management via cookies
✅ Secure password storage

All you need is your SMTP credentials added to your Docker Compose file. I use Resend for email delivery — it's straightforward to set up and works reliably. Everything else is handled by Directus out of the box.

This is the auth setup I use across all my TanStack Start projects. Combined with Directus roles and permissions, it covers everything a production app needs without adding a separate auth service to your stack.

Have questions about the setup? Drop a comment below.

Why I Switched to a VPS with Coolify for Hosting My Full Stack Apps

Wade Thomas — Mon, 30 Mar 2026 04:22:24 +0000

There are plenty of great hosting options out there — Netlify, Vercel, Railway and more. I've tried a few of them and they all have their place. But after going through a few different setups, I landed on a VPS managed with Coolify and it's been the best experience for my workflow.

Here's how I got there.

Where I Started

I started with Netlify. It's beginner friendly, deployment is simple and it works well for frontend projects. I then tried Vercel and that was also a solid experience — great DX, fast deploys, good defaults.

Both are genuinely good platforms. But as my projects grew more complex — running a frontend, a Directus instance, a database — the platform costs and constraints started to feel limiting.

The Raw VPS Experiment

I decided to try self-hosting on an Ubuntu VPS with Nginx as my web server and reverse proxy. Manually configuring everything — SSL, domains, process management, deployments. It was a solid learning experience and I'd recommend it to anyone who wants to understand how hosting actually works under the hood.

But it wasn't the ideal long-term setup. Too much manual work, too much that could go wrong quietly.

Discovering Coolify

Coolify changed things. It's a self-hosted platform that sits on top of your VPS and gives you:

Automatic deployments — push code and your frontend deploys automatically via Git integration
Docker Compose support — I manage my Directus instance and PostgreSQL database through Coolify using Docker Compose, which keeps everything clean and reproducible
Reverse proxy handled for you — no more manually writing Nginx configs
SSL out of the box — certificates are handled automatically
No hidden fees — you pay for the VPS, that's it. Coolify itself is free to self-host

Full Control, Your Way

With a VPS you decide how it's configured. You're not subject to platform pricing changes, compute limits, or vendor lock-in. Everything runs on infrastructure you control.

The tradeoff is responsibility — you manage the server, handle updates, and own any issues that come up. It's not the right fit for everyone.

Is It Worth It?

If you're comfortable with a bit of server management and want a flexible, cost-effective setup for running full stack apps, a VPS with Coolify is hard to beat. It's the sweet spot between the ease of a managed platform and the control of raw infrastructure.

For my stack — TanStack Start on the frontend, Directus as the backend, PostgreSQL as the database — it handles everything cleanly in one place.

Have questions about the setup or want to know if it's a good fit for your project? Drop a comment below.

Why I Use Directus as My Backend — Flexible, Self-Hosted and Production Ready

Wade Thomas — Mon, 30 Mar 2026 04:15:39 +0000

If you're looking for a backend that's flexible, affordable and genuinely enjoyable to work with, Directus is worth a serious look.

Here's why it's become my default choice for full stack projects.

Free to Self-Host (With a Sensible Threshold)

Directus uses a BSL 1.1 license. If your organization has less than $5M in total annual income — revenue and funding combined — you can self-host it for free across all your projects, including production and commercial ones. No feature paywalls, no artificial limits.

Once you're past that threshold, a commercial license is required. But for the vast majority of indie developers, freelancers, startups and small teams, it's completely free.

Works with Any SQL Database

Directus sits on top of your existing database rather than replacing it. It supports PostgreSQL, MySQL, SQLite, MariaDB and more. My preference is PostgreSQL — pair them together and you get a rock solid data layer with Directus handling the API, auth, and admin UI on top.

Flexible Data Structures

Whether you're building a simple blog, an e-commerce store, or a complex multi-tenant app, Directus adapts to your data model. You define your collections and fields, and Directus generates a full REST and GraphQL API automatically. No rigid schema to fight against.

Built-In Features That Scale With You

Starting small? Directus is simple enough to get up and running fast. Ready to grow? It has you covered:

Authentication — built in, with session and token support
Roles and Permissions — granular access control per collection and field
Automation — flows and webhooks for backend logic without extra services
Dashboard — a full admin UI out of the box for managing your data
File Management — upload, transform and serve assets directly

Actively Maintained

Directus is backed by a strong team of developers and an active open source community. It's regularly updated, well documented, and not going anywhere. That matters when you're building something you plan to maintain long term.

Who It's For

Startups — get a full backend running quickly without over-engineering
Freelancers — one backend you can reuse across different client projects
Growing products — the feature set scales as your requirements do
Developers who want control — self-host it, own your data, no vendor lock-in

I use Directus with TanStack Start on the frontend and the Directus SDK for all data fetching. If you're exploring it for your next project and want to see how the integration works in practice, I've covered the SDK setup and data fetching patterns in previous posts on my profile.

Have a project in mind and want to know if Directus is the right fit? Drop a comment and I'm happy to help.

TanStack Start: Metadata, Data Loading and Loading Skeletons in One Route File

Wade Thomas — Mon, 30 Mar 2026 04:11:22 +0000

TanStack Start has become my go-to for full stack React apps. One of the things I enjoy most about it is how cleanly it handles three things that are usually spread across multiple files and libraries — metadata, data fetching, and loading UI — all colocated in a single route.

Here's how I use head, loader, and pendingComponent together.

head — Per-Route Metadata

head lets you define document-level metadata per route. Page title, meta description, open graph tags — all scoped to that route without a global workaround or a third party head manager.

head: () => ({
  meta: [
    { title: 'All Articles — Big Cats' },
    { name: 'description', content: 'Every story, every species.' },
  ],
}),

Each route owns its own SEO info. No context providers, no helmet libraries, no prop drilling.

loader — Data Fetching Before Render

loader is where you fetch everything your route needs. It runs on the server or client depending on your SSR config, and the data it returns is available in your component via useLoaderData. Parallel fetches with Promise.all are the standard pattern here.

loader: async () => {
  const [posts, categories] = await Promise.all([
    getPosts(),
    getCategories()
  ])
  return { posts, categories }
},

Both fetches run in parallel — no waterfall, no useEffect, no loading state management in the component. The data is just there when the component renders.

pendingComponent — Skeleton While the Loader Resolves

pendingComponent renders while the loader is still resolving. It's the right place for skeletons or placeholder UI. The pendingMs and pendingMinMs options give you timing control — useful for avoiding a skeleton flash on fast connections while still showing it on slow ones.

pendingComponent: () => (
  <main className="min-h-screen bg-black text-white">
    <section className="border-b border-white/10 px-6 py-16 text-center">
      <h1 className="text-4xl font-bold tracking-tight md:text-6xl">
        All Articles
      </h1>
      <p className="mt-3 text-white/50">Every story, every species.</p>
    </section>
    <section className="mx-auto max-w-6xl px-6 py-16">
      <PostGridSkeleton />
    </section>
  </main>
),

The layout and headings render immediately while PostGridSkeleton holds the place for the actual content. The page feels instant even on slower connections.

All Together in One Route

What I appreciate most is that all three live in the same route file. The metadata, the data fetching, and the loading UI are colocated — no jumping between files to understand what a route does.

export const Route = createFileRoute('/articles')({
  head: () => ({
    meta: [
      { title: 'All Articles — Big Cats' },
      { name: 'description', content: 'Every story, every species.' },
    ],
  }),
  loader: async () => {
    const [posts, categories] = await Promise.all([
      getPosts(),
      getCategories()
    ])
    return { posts, categories }
  },
  pendingComponent: () => (
    <main className="min-h-screen bg-black text-white">
      <section className="border-b border-white/10 px-6 py-16 text-center">
        <h1 className="text-4xl font-bold tracking-tight md:text-6xl">
          All Articles
        </h1>
        <p className="mt-3 text-white/50">Every story, every species.</p>
      </section>
      <section className="mx-auto max-w-6xl px-6 py-16">
        <PostGridSkeleton />
      </section>
    </main>
  ),
})

If you're evaluating TanStack Start for your next full stack project, this colocation pattern alone is worth the look. Everything your route needs — SEO, data, loading UI — in one place.

I pair this with Directus as my CMS and Tailwind CSS v4 for styling. The getPosts() and getCategories() calls come from a single directus.ts file using the Directus SDK — I covered that setup in a previous post if you want to see how that layer is structured.