DEV Community: Vincent Boon

Docker environment for Laravel/Statamic package development

Vincent Boon — Mon, 06 Apr 2026 19:38:07 +0000

I’ve recently added a new feature to Vigilant, health checks. Vigilant is an open source monitoring application that is designed to monitor all aspects of a website. With health checks we can verify if critical processes are running such as a Laravel scheduler or Redis connection. Additionaly alongside these boolean type of checks I’ve added metrics which allow us to expose basic system statistics such as cpu, memory and disk space. We can even add the size of the log files in the app to get notified when these values peak!

I created a healthcheck-base package to define a common interface. Framework-specific packages build on top of this and integrate seamlessly, while remaining usable without Vigilant.

Then separate packages which add Laravel or Statamic specific checks at:

These are designed to work without Vigilant but integrate seamlessly.

Package development

The usual method for package development would be to add the directory as a composer repository in an existing project and let composer make a symlink. This is documented here and a good way for development.

I recently saw that one of Statamic’s core developer Duncan McClean created an opinionated script called tether do manually do these symlinks. I’ve personally done the same with a simpler script that I wrote to avoid having to manually edit the composer json every time I need to work on a package, here is the script:

#!/bin/bash
# Link a local package in a Laravel project
# Usage: lpackage.sh <package-name>
projects_path=$HOME/code
package=$1
composer=$(which composer)
vendorTarget=$(find vendor -maxdepth 2 -type d -name $package)
if [ -z "$vendorTarget" ]; then
    echo "Package not found in vendor directory"
    exit 1
fi
packagePath=$(find $projects_path -maxdepth 1 -type d -name $package)
if [ -z "$packagePath" ]; then
    echo "Package not found in projects directory"
    exit 1
fi
echo "Linking $packagePath to $vendorTarget"
rm -rf $vendorTarget
ln -s $packagePath $vendorTarget
echo "Reinstalling package dependencies"
rm -rf $packagePath/composer.lock $packagePath/vendor
$composer --working-dir=$packagePath install &> /dev/null
echo "Done!"

In combination with an alias alias lpackage="sh ~/dotfiles/scripts/lpackage.sh" this can be ran from a project directory to link any package with the prerequisite that the target package is already installed in the project. This script is intentionally minimal and tailored to my local setup

The downside of this is that you have to have an pre existing project which isn’t a clean project so you always run the risk of something in the project affecting your package. A small example is calling Model::unguard() in the project's service provider which is easy to miss in a package but will causes issues when the package is included in another project.

Don’t get me wrong, these methods are perfectly fine but sometimes it’s nice to have a clean install for a package so you are absolutely sure it works.

Let’s build a Docker environment

This environment needs to setup a clean application and install our package. Preferably symlink to our package so that our changes are effective immediately. I’m going to use Docker compose to setup additional services like MySQL and Redis. I also want to setup things like an admin account in the case of Statamic so we don’t have to create one each time the stack starts. Let’s start with the Dockerfile, to reduce overhead we’ll be using artisan serve to handle requests and schedule:work instead of cron. To run these we'll use supervisor.

So what do we have to do?

Pick a base image for our container
Add the required dependencies
Install composer and create a new Laravel / Statamic project
Install our package
Run the required services

Let’s start with the base image, I’ve chosen to use php:8.5-cli which is a Debian based image that includes PHP 8.5. So the start of our Dockerfile looks like this:

FROM php:8.5-cli WORKDIR /srv

Then we need to install our dependencies such as supervisor and PHP extensions:

RUN apt-get update \
    && apt-get install -y --no-install-recommends git unzip libzip-dev supervisor \
    && docker-php-ext-install zip pcntl \
    && pecl install redis \
    && docker-php-ext-enable redis \
    && rm -rf /var/lib/apt/lists/*

We can get composer and create the project:

COPY --from=composer:2 /usr/bin/composer /usr/bin/composer
RUN composer create-project --no-interaction --no-progress laravel/laravel app
// Or for Statamic:
RUN composer create-project --no-interaction --no-progress statamic/statamic app

Now that we’ve got a project setup we can copy our package and install it along with some other setup stuff:

COPY . /srv/package
WORKDIR /srv/app
RUN composer config minimum-stability dev \
    && composer config prefer-stable true \
    && composer config repositories.statamic-healthchecks path /srv/package \
    && composer require --no-interaction --no-progress govigilant/statamic-healthchecks:dev-main laravel/horizon \
    && php artisan key:generate \
    && php artisan horizon:install

And finally we can copy the supervisor config and start it:

RUN rm -rf /var/www/html \
    && mv /srv/app /var/www/html \
    && mkdir -p /var/log/supervisor
WORKDIR /var/www/html
COPY devenv/supervisord.conf /etc/supervisor/conf.d/healthchecks.conf
EXPOSE 8000
CMD ["supervisord", "-n"]

Here is the final Dockerfile:

FROM php:8.5-cli
WORKDIR /srv
RUN apt-get update \
    && apt-get install -y --no-install-recommends git unzip libzip-dev supervisor \
    && docker-php-ext-install zip pcntl \
    && pecl install redis \
    && docker-php-ext-enable redis \
    && rm -rf /var/lib/apt/lists/*
COPY --from=composer:2 /usr/bin/composer /usr/bin/composer
RUN composer create-project --no-interaction --no-progress laravel/laravel app
COPY . /srv/package
WORKDIR /srv/app
RUN composer config minimum-stability dev \
    && composer config prefer-stable true \
    && composer config repositories.statamic-healthchecks path /srv/package \
    && composer require --no-interaction --no-progress govigilant/statamic-healthchecks:dev-main laravel/horizon \
    && php artisan key:generate \
    && php artisan horizon:install
RUN rm -rf /var/www/html \
    && mv /srv/app /var/www/html \
    && mkdir -p /var/log/supervisor
WORKDIR /var/www/html
COPY devenv/supervisord.conf /etc/supervisor/conf.d/healthchecks.conf
EXPOSE 8000
CMD ["supervisord", "-n"]

Statamic user

For statamic we need a user to login to the control panel, for this I’ve created a users directory in the package repository. Then in the Dockerfile I copy that into the Statamic folder: _COPY devenv/users/ /srv/app/users/_

The supervisor config looks like this, to avoid stdout being spammed I’ve put the logs in separate files:

[supervisord]
nodaemon=true
[program:php]
command=php artisan serve --host=0.0.0.0 --port=8000
directory=/var/www/html
autostart=true
autorestart=true
stdout_logfile=/var/log/supervisor/php.log
stderr_logfile=/var/log/supervisor/php.err.log
[program:horizon]
command=php artisan horizon
directory=/var/www/html
autostart=true
autorestart=true
stdout_logfile=/var/log/supervisor/horizon.log
stderr_logfile=/var/log/supervisor/horizon.err.log
[program:scheduler]
command=php artisan schedule:work
directory=/var/www/html
autostart=true
autorestart=true
stdout_logfile=/var/log/supervisor/scheduler.log
stderr_logfile=/var/log/supervisor/scheduler.err.log

Let’s break this down quickly, it starts the following services:

php artisan serve — host=0.0.0.0 — port=8000 — For handling HTTP requests
php artisan horizon — For verifying if the Horizon checks in the package work
php artisan schedule:work — For verifying if the scheduler check in the package works

If you don’t know, supervisor is a program which lets you run other programs. When something crashes, supervisor will start it again. It’s a useful tool to keep services running with relatively simple configuration.

Now that we have a Dockerfile we can create a compose file. This is what we use to compose the stack together, it defines the services we need including our clean application. With this file we can start the entire stack with a single command and because it’s all containerized we can be sure it’s the same on each host system.

Notice that instead of an image for the app container we pass our Dockerfile. We map the package and environment file to the app container. This env file contains some basic configuration for the database, redis and package configuration.

services:
  app:
    build:
      context: ..
      dockerfile: devenv/Dockerfile
    ports:
      - "8000:8000"
    volumes:
      - ../:/srv/package
      - ./app.env:/var/www/html/.env
    depends_on:
      - mysql
      - redis
  mysql:
    image: mysql:8.4
    environment:
      MYSQL_ROOT_PASSWORD: secret
      MYSQL_DATABASE: laravel
      MYSQL_USER: laravel
      MYSQL_PASSWORD: secret
    volumes:
      - mysql-data:/var/lib/mysql
  redis:
    image: redis:7-alpine
    command: ["redis-server", "/usr/local/etc/redis/redis.conf"]
    volumes:
      - ./redis.conf:/usr/local/etc/redis/redis.conf
volumes:
  mysql-data:

And that’s it, we now have a dedicated clean environment to develop and test our package.

Further possibilities

Right now I’m using this for development and I run these on a test server (not accessible from the internet) for testing the server side of healthchecks. I have a small script which updates each one by pulling the git changes and rebuilding the containers.

It might also be a nice addition to spin up this Docker image in a pipeline to run an integration test for example.

Upgrading to Statamic 6

When Statamic 6 was released, I needed to upgrade the statamic-healthchecks addon to be compatible with it. This meant updating the statamic/cms constraint in composer.json from ^5.0 to ^6.0, updating the CI matrix, and migrating the Vue 2 frontend assets to Vue 3. Once the code changes were done, I needed to verify it all works end-to-end and this is exactly where the Docker environment proved its value.

Without a dedicated environment I would have had to manually update an existing Statamic project, install the package there, and test it. With the Docker setup, I just rebuilt the image. The build process runs composer create-project statamic/statamic from scratch every time, so a rebuild gave me a clean Statamic 6 install with the updated package installed.

The container started cleanly and the health check endpoint returned the expected response including the Statamic-specific statamic_stache check. The upgrade was verified against a clean Statamic 6 install without touching any existing project.

Should all packages ship an environment like this?

Absolutely not. It depends on the package and the goals. The goal here is to have a clean install to test the package and to spin up a testing environment. The ‘traditional’ way of symlinking a package in a project is in most cases still the preferable way in most cases. So for most packages symlinking is enough. But when, a clean, reproducible setup is needed, Docker is hard to beat.

Originally published at https://govigilant.io on April 6, 2026.

How to catch CVE’s on time

Vincent Boon — Tue, 31 Mar 2026 17:53:43 +0000

What is a CVE?

Common Vulnerabilities and Exposures (CVE) is the industry standard way of publishing security vulnerabilities in software. It dates back to 1999 and was funded by the US government.

CVE’s are published as numbers starting with CVE and the year followed by a number: CVE-{year}-{number}. For example CVE-2025-55182. Each CVE is for one vulnerability, a description is added explaining the issue and a score indicates how urgent it is. For example, CVE-2025-55182 has a severity score of 10, this is very bad and needs to patched as fast as possible.

The severity is typically measured using the CVSS (Common Vulnerability Scoring System). A high score, such as 10, indicates a critical vulnerability that should be patched immediately, while a lower score suggests the issue is harder to exploit or has less severe consequences.

What happens when a CVE is published for software I use?

When a CVE is published for software you use, it means a publicly known security vulnerability has been identified in one of your dependencies, services, or systems. At that point, attackers may begin analysing the vulnerability, and in some cases exploits become available very quickly.

Typically, the software vendor will release a security advisory and, if possible, a patched version or mitigation guidance. Your responsibility is to determine whether you are affected, assess the severity of the issue, and decide how urgently it needs to be addressed.

If the vulnerable component is exposed to the internet or runs with high privileges, even a medium-severity CVE can be a serious risk. On the other hand, a critical CVE might be less urgent if the affected feature is not enabled or reachable in your environment. Understanding the CVE details and your own setup is essential for determining the right action.

Where to find CVE’s

One of the primary sources for CVE information is the National Vulnerability Database (NVD). The NVD aggregates CVE data and enriches it with severity scores, affected products, and additional metadata. It serves as the authoritative reference for many tools and security teams, even though it may not always be the fastest source when a vulnerability is first disclosed.

Many other organizations and governments consume and republish this same data. For example, the Dutch National Cyber Security Centre (NCSC) publishes CVE information and security advisories based on NVD data, often adding local context and guidance for organizations in the Netherlands. Similar initiatives exist in other countries, providing region-specific recommendations while relying on the same underlying CVE identifiers.

Because most of these platforms are derived from the same source, they tend to contain largely overlapping information. The main differences are in how the data is presented, enriched, or prioritized, rather than in the CVEs themselves.

While the NVD is a comprehensive and authoritative source, manually browsing it is cumbersome and inefficient. Hundreds of new or updated CVEs are added every week, many of which will never apply to your software, infrastructure, or configuration.

Searching through the database, reading individual entries, and determining relevance requires significant time and expertise. Even then, it’s easy to miss important details such as affected versions, specific configurations, or whether a vulnerability is actually exploitable in your environment.

For small environments this may be manageable, but as your software stack grows, manual CVE tracking quickly becomes impractical. This is why most teams move away from manual monitoring and rely on automation, filtering, and tooling to surface only the vulnerabilities that truly matter.

Method One: Hope you find it

The least effective way to catch CVEs is to simply hope you stumble across them. This usually means finding out about a vulnerability through news articles, social media, blog posts, or after someone else points it out.

While vulnerabilities with high CVSS scores sometimes make headlines, most CVEs never do. Many serious issues are quietly disclosed in vendor advisories or databases like the NVD, without widespread attention. Relying on chance means you’re likely to learn about vulnerabilities late or not at all.

This approach also tends to be reactive rather than proactive. By the time a vulnerability is trending online, attackers may already be exploiting it. In short, hoping to “hear about it” is unreliable and risky and doesn’t scale.

Method Two: Mailing lists

Mailing lists are a more proactive way to learn about new CVEs. Many software vendors, open-source projects, and security communities publish vulnerability disclosures through dedicated security mailing lists. Subscribing to these can give you early visibility into issues that affect the software you use.

Examples include vendor-specific security lists, open-source project announcements, and broader security lists such as OSS-Security. These often contain detailed technical information, mitigation steps, and links to patches, making them valuable for understanding the real impact of a vulnerability.

However, mailing lists come with their own challenges. They can be noisy, unstructured, and difficult to filter. Important alerts may get buried among less relevant messages, and keeping track of multiple lists quickly becomes overwhelming. While mailing lists are a significant improvement over hoping to find a CVE by chance, they still require manual effort and constant attention.

Method Three: Automated tools

Automated tools are by far the most reliable way to track CVEs at scale. These tools continuously monitor CVE databases and advisories, match vulnerabilities against your software stack, and alert you when something relevant appears. This removes most of the manual work and significantly reduces the chance of missing critical issues.

Enterprise security platforms like CrowdStrike Spotlight offer deep integration, asset awareness, and prioritization based on real-world exploitability. The downside is cost, these solutions are powerful, but often out of reach for smaller teams or individual developers.

There are also more accessible alternatives. OpenCVE, for example, is an open-source and self-hostable platform that tracks CVEs and allows you to subscribe to specific vendors or products. It provides a good balance between control and automation, especially if you’re comfortable running your own tooling.

Another option is Vigilant, which focuses specifically on website monitoring and includes CVE monitoring. It provides alerts and filtering to help you focus on vulnerabilities that matter to you, without requiring a full enterprise security stack. Tools like this are well-suited for teams that want timely notifications without the overhead of heavy infrastructure.

Automated tools turn CVE tracking from a manual, error-prone task into a continuous background process. While no tool completely replaces human judgment, automation is essential if you want to catch CVEs on time and respond before they become incidents.

How to choose the right method

The right way to track CVEs depends on what you are responsible for securing. For general software projects or libraries, a tool like OpenCVE can be sufficient, as it allows you to subscribe to specific products and vendors.

However, website owners face a unique set of challenges. Websites are built from components that change over time. CMS platforms, themes, plugins, and third-party dependencies and keeping all of these safe involves more than just checking for raw CVE publications. Vigilant’s integrated monitoring means you can track vulnerabilities alongside uptime, broken links, performance, certificates, and DNS issues, all in one dashboard and with minimal setup.

As soon as security becomes an ongoing responsibility rather than an occasional task, manual tracking stops working. For website owners, tools that focus on real exposure, automatic detection, and clear alerts are essential.

Ultimately, the best method is the one that tells you when your website is actually at risk, without overwhelming you with irrelevant information. For website owners, that means using a tool built specifically for monitoring websites.

Conclusion

CVE tracking is essential for keeping software and websites secure, but the sheer volume of vulnerabilities published each week makes manual monitoring impractical. From hoping to stumble across CVEs online, to following mailing lists, to using automated tools, there are clear trade-offs in effectiveness, effort, and coverage.

For website owners, automated platforms like Vigilant provide a practical solution. By monitoring your site’s technologies and alerting you to relevant vulnerabilities, they turn CVE tracking from a time-consuming task into a continuous, actionable process. Combined with broader monitoring features, these tools help ensure that you catch critical issues before they can be exploited.

Ultimately, staying on top of CVEs requires a combination of the right tools, smart prioritization, and consistent attention. Using automation tailored to your environment lets you focus on what really matters: keeping your systems and websites secure.

Originally published at https://govigilant.io on March 30, 2026.

How To Prevent Website Downtime

Vincent Boon — Thu, 26 Mar 2026 19:59:00 +0000

Downtime can happen for many reasons: infrastructure failures, network issues, software bugs, or simple configuration mistakes. Some of these problems are unavoidable, but most can be prevented by understanding how websites work and where failures typically occur.

In this article, we’ll break down how downtime happens, how traffic reaches your website, and what can go wrong along the way. More importantly, we’ll look at practical ways to reduce risk through better architecture, multiple environments, and effective monitoring. The goal is not just to react faster to outages, but to prevent them from happening in the first place.

How Downtime Happens

Downtime occurs when your website is unable to respond correctly to incoming requests. This doesn’t always mean the server is completely offline. A website can be considered “down” when it returns errors, times out, or becomes so slow that users effectively can’t use it.

In many cases, downtime is the result of a chain of failures rather than a single event. A small configuration change, an unexpected spike in traffic, or a failing dependency can cascade into a full outage. Because modern websites are made up of multiple components, a problem in any one of them can make the entire site unreachable.

It’s also important to distinguish between partial and total downtime. Partial downtime might affect only certain pages, users, or regions, while total downtime means no one can access the site at all. Both are damaging, but partial outages are often harder to detect without proper monitoring in place.

Understanding how downtime happens is the first step toward preventing it. To do that, it helps to look at how traffic actually reaches your website and how many points of failure exist along that path.

How Traffic Reaches Your Website

When a user visits your website, a lot happens behind the scenes before a page is displayed. It normally goes so fast that you probably don’t even notice how many things are happening. Each step in this process introduces a potential point of failure, which is why understanding the request flow is essential for preventing downtime.

It starts with a DNS lookup. When someone types your domain name in their browser a lookup takes place. The user’s browser must know where to go to reach your website. This is done through the Domain Name System (DNS) which returns the IP address of your server.
If DNS is misconfigured or unavailable, the request never reaches your infrastructure at all. Incorrect changes can also leave your site unavailable as DNS updates are slow and can take hours.

Once the correct IP address is found, the browser establishes a network connection to your server. This connection passes through multiple networks and routers before reaching your hosting provider. Even if your server is healthy, network issues along this path can prevent users from connecting.

After the connection is established, the web server processes the request. This may involve application logic, databases, external APIs, or background services. If any of these components fail or respond too slowly, the request can time out or return an error.

Finally, the server sends a response back to the user’s browser. If everything works as expected, the page loads. If not, the user experiences an error, a blank page, or excessive loading times which are often perceived as downtime.

Because traffic depends on so many interconnected systems, preventing downtime means identifying which parts are most likely to fail and preparing for those failures in advance.

Where Things Can Go Wrong

Now that we understand how traffic reaches your website, it becomes clear how many things can fail along the way. Even simple websites depend on multiple layers of infrastructure and software, and a problem in any of these layers can result in downtime.

Most website outages fall into three broad categories: server failures, network failures, and website code failures. While the symptoms may look similar to users, errors, timeouts, or blank pages the underlying causes are very different. Identifying which category a problem belongs to is crucial for preventing it from happening again.

Let’s look at each of these failure types in more detail, starting with server-related issues.

Server Failures

Server failures are one of the most common causes of website downtime. Even when your code is correct and your network is stable, the underlying machine running your website can still fail.

A server can go down for many reasons. Hardware issues, operating system crashes, or forced reboots by the hosting provider can instantly make your website unavailable. In virtualized or cloud environments, servers may also be terminated or migrated without warning if resource limits are exceeded.

Resource exhaustion is another frequent cause. When a server runs out of CPU, memory, or disk space, it may slow down dramatically or stop responding altogether. This often happens during traffic spikes, background jobs running at the wrong time, or memory leaks in long-running processes.

Misconfiguration can be just as damaging. Incorrect web server settings, broken service dependencies, or failed updates can prevent the server from starting properly. In these cases, the server may be online, but unable to serve requests correctly.

Because servers are a single point of execution for your application, failures at this level tend to have an immediate and visible impact. Reducing downtime means not only choosing reliable infrastructure, but also monitoring server health and preparing for failure rather than assuming stability.

Network Failures

Network failures occur when users are unable to reach your server, even if the server itself is running correctly. These issues are often harder to diagnose because the problem may exist outside of your direct control.

One common cause is DNS-related problems. Incorrect DNS records, expired domains, or outages at DNS providers can prevent traffic from resolving to your server’s IP address. When this happens, users never reach your infrastructure at all.

Routing issues between networks can also cause downtime. Traffic on the internet passes through multiple autonomous systems before reaching your hosting provider. If a routing path is misconfigured or temporarily unavailable, users in certain regions may experience outages while others do not. This is why it’s important to monitor from multiple locations around the world.

Firewalls and security rules are another frequent source of network-related downtime. Overly strict rules, accidental IP blocks, or misconfigured rate limits can block legitimate traffic. From a user’s perspective, this looks exactly like the website is down.

Because network failures can be regional or intermittent, they are easy to miss without external monitoring. Preventing these issues requires careful configuration, redundancy where possible, and visibility into how your website is accessed from different locations.

Website Code Failures

Website code failures happen when the application itself is unable to handle requests correctly. Unlike server or network issues, these failures often occur immediately after a change is made, such as a deployment or configuration update. But with aggressive caching it may also take some time for issues to reach users.

Bugs in application logic can cause errors that prevent pages from loading or APIs from responding. An unhandled exception, infinite loop, or missing dependency can crash a process or return repeated server errors. In some cases, a single faulty request can degrade performance for all users.

Changes to code or configuration are a common trigger. Deployments that haven’t been properly tested may introduce breaking changes, incompatible library versions, or invalid settings. Even small changes can have large effects if they impact core request handling or database access.

External dependencies can also cause code-related downtime. If your application relies on third-party APIs, payment providers, or authentication services, failures in those systems can cascade into your own application. Without proper timeouts and fallbacks, your website may hang or fail entirely.

Because code failures are often self-inflicted, they are also among the most preventable. Clear deployment practices, proper testing, and good error handling significantly reduce the risk of taking a website offline through software changes.

How to Prevent Each Type of Problem

Preventing website downtime starts with addressing each failure category directly. While no system can be made completely failure-proof, you can significantly reduce both the frequency and impact of outages by designing for failure and adding safeguards at every layer.

Instead of relying on a single fix, effective prevention combines infrastructure choices, configuration discipline, and operational practices. The goal is to detect problems early, limit their blast radius, and recover quickly when something does go wrong.

Below, we’ll look at practical steps to prevent downtime caused by server issues, network problems, and website code failures.

Preventing Server Failures

Reducing server-related downtime begins with eliminating single points of failure. Relying on one server means that any crash, reboot, or resource issue will immediately take your website offline. Using multiple servers or managed platforms with built-in redundancy greatly improves resilience.

Monitoring server health is equally important. Tracking CPU usage, memory consumption, disk space, and running processes helps identify problems before they cause outages. Automated alerts allow you to respond quickly when thresholds are exceeded.

Automated recovery can further reduce downtime. Restarting crashed services, replacing unhealthy instances, or scaling resources during traffic spikes can often resolve issues without manual intervention. These mechanisms ensure that short-lived problems don’t turn into prolonged outages.

Finally, keep servers predictable. Apply updates carefully, document configuration changes, and avoid unnecessary complexity. Stable, well-understood systems fail less often and are easier to recover when they do.

Preventing Network Failures

Preventing network-related downtime is about ensuring users can reach your website reliably, even when parts of the network experience issues. While you can’t control every network between your server and users, careful configuration and monitoring can reduce risks.

Start with a solid DNS setup. Use reputable DNS providers and ensure redundancy with multiple authoritative name servers. Correct configuration and monitoring DNS records help to know when something is modified.

Pay close attention to firewall and security rules. Overly strict rules, accidental IP blocks, or misconfigured access controls can prevent legitimate users from reaching your site. Logging and monitoring network traffic helps identify these issues before they affect users.

Routing problems within your own network or hosting provider can also cause outages. Redundant network interfaces, proper routing configurations, and regular connectivity checks help ensure traffic continues to flow even when part of the network fails. Choose a reliable hosting provider for this.

Finally, monitor accessibility from multiple locations. Network failures can be regional, and relying on a single test point may not reveal them. Multi-location monitoring ensures you catch problems that affect only some users.

Preventing Website Code Failures

Preventing downtime caused by website code requires discipline in development, testing, and deployment. Unlike server or network issues, these failures are often within your control, which makes them highly preventable.

The first step is thorough testing. Unit tests, integration tests, and automated end-to-end tests help catch errors before they reach production. Testing should cover both expected use cases and edge cases that could cause failures under load or unusual conditions.

Staged deployments are also critical. Deploying changes first to a development or staging environment allows you to verify functionality and performance before affecting real users. This minimizes the risk of introducing breaking changes directly to production.

Version control and rollback strategies provide safety nets. If a deployment introduces an unexpected bug, having a tested rollback plan allows you to restore the previous working version quickly, minimizing downtime.

Finally, implement robust error handling in your code. Timeouts, retries, and graceful degradation prevent single points of failure from crashing the entire application. Even when something goes wrong, your website can continue serving users without a full outage.

Setup Multiple Environments

One of the most effective ways to prevent downtime is to use multiple environments for your website: development, staging, and production. Each environment serves a distinct purpose and provides a controlled space to test changes before they affect real users.

Development environments are where new features and bug fixes are built. Developers can experiment, run tests, and identify issues without risking production downtime.

Staging environments mirror production as closely as possible. This is where you validate deployments, test integrations, and simulate real-world traffic. Staging allows you to catch configuration mistakes, performance issues, or code regressions before they reach your live site.

Production is where your website serves real users. By the time code reaches this environment, it should already be thoroughly tested and verified in development and staging.

Using multiple environments creates a safety net. Problems are discovered earlier, deployments become more predictable, and the risk of downtime caused by human error or unforeseen bugs is greatly reduced. It also supports better monitoring and rollback strategies, since you can test fixes in staging before applying them to production.

Monitoring: The Key to Prevention

Even with strong infrastructure and careful development practices, issues can still happen. That’s why monitoring isn’t just a safety net. It’s a core part of preventing downtime. Monitoring gives you visibility into your site’s health so you can detect and respond to problems before your users notice.

One powerful tool for this is Vigilant, a monitoring platform designed to watch your website from outside your infrastructure and alert you instantly when something goes wrong. Unlike simple “is it online” checks, Vigilant helps you spot real problems that affect your users and your business.

Instant Uptime Alerts

Vigilant continuously checks your website from multiple global locations and alerts you as soon as your site stops responding. Because it verifies outages from more than one location before notifying you, you avoid false alarms and only act on real issues. This ensures you know about actual downtime quickly before customers notice or conversions are lost.

Historical Data and Reliability Metrics

Knowing when and how often downtime happens is critical to improving reliability. Vigilant stores detailed historical data with timestamps that help you identify patterns, measure uptime percentages, and track whether your prevention efforts are working over time.

Beyond Uptime

Good monitoring goes beyond simple reachability. Vigilant includes additional checks that help catch the kinds of failures that don’t always look like downtime but still harm user experience:

Link issue detection to catch broken internal URLs
DNS monitoring so misconfigurations or unexpected changes don’t take your site offline
Certificate monitoring to warn you before HTTPS certificates expire and trigger browser warnings
Performance tracking (Lighthouse) to spot slowdowns that lead to churn These extended checks broaden your visibility and help prevent subtle failures from becoming major outages.

Smart, customizable Notifications

A monitoring system is only useful if you actually see its alerts. Vigilant supports notifications through the channels you already use. Email, Slack, and others so you can react in minutes instead of hours when something goes wrong.

Easy to Set Up and Use

Vigilant is designed to get started quickly. You simply add your site and configure the monitors you want, and Vigilant begins tracking uptime and other metrics almost immediately. Its sensible defaults mean you don’t need deep expertise to begin protecting your site.

Advanced Options

For websites with high traffic or strict uptime requirements, there are additional strategies that go beyond basic monitoring and environment separation. These advanced options help your site remain available even under unusual conditions or extreme load.

Distributed or Multi-Region Architecture

Deploying your website across multiple regions reduces the impact of a single server or datacenter failing. If one region experiences an outage, traffic can be routed to another region, keeping your site online for most users. This approach is especially useful for global websites where downtime in one area can affect a large number of users.

Load Balancers & Failovers

Load balancers distribute incoming traffic across multiple servers, preventing any single server from becoming a bottleneck. They can automatically reroute traffic to healthy servers if one fails, providing seamless failover. Combined with redundant infrastructure, this ensures that individual failures don’t result in visible downtime.
Do ensure you have multiple load balancers, otherwise you’re just moving the single point of failure ;)

Auto-Scaling to Handle Traffic Spikes

Unexpected spikes in traffic are a common cause of downtime, especially for events, product launches, or viral content. Auto-scaling automatically adds server capacity when load increases and scales down during quieter periods. This ensures your site remains responsive without over-provisioning resources all the time.

These advanced techniques require careful planning and investment, but they significantly increase resilience and reduce the risk of downtime. They are most beneficial for sites where availability is critical to revenue, reputation, or user trust.

Conclusion

Website downtime can happen to anyone, but most outages are preventable. By understanding how traffic reaches your website and where failures can occur, you can take proactive steps to protect your site.

Start with solid infrastructure and multiple environments, implement careful deployment and testing practices, and use vigilant monitoring to catch issues before they affect users. For high-traffic or mission-critical websites, advanced strategies like multi-region deployments, load balancing, and auto-scaling provide an additional layer of resilience.

Ultimately, preventing downtime isn’t about avoiding every possible problem, it’s about designing systems, processes, and monitoring in a way that allows you to detect issues quickly, respond effectively, and keep your website online and performing for your users.

Originally published at https://govigilant.io on March 25, 2026.

The 7 Levels of Website Monitoring -Learn how to monitor your entire website

Vincent Boon — Sat, 21 Mar 2026 18:26:03 +0000

Why monitor your website?

When your business depends on your website it is essential that it’s functioning correctly. Downtime, slow pages or important functions, such as an add to cart button, not working can have serious consequences.
You can of course manually verify if these things are working but that’s not an effective use of your time and you will probably find out when the damage is already done.

This is where monitoring your website comes in, it will automate these checks for you and notify you when something goes wrong.

Level 0 - No monitoring

At level 0 there is no automated monitoring at all. The only way you know if something is wrong is by manually checking your website or hope a user tells you.

This usually looks like:

The problem isn’t that manual checks don’t work. It’s that they are a waste of your valuable time and they’re not continuous.

Websites don’t break on your schedule. They break at 3 AM, during deployments, after dependency updates, or when traffic spikes. A quick check in the morning tells you nothing about what happened overnight.

Even worse, manual checks are reactive. You only notice issues after:

For hobby projects or internal tools with zero impact, level 0 might be acceptable. For anything even remotely business-critical, it’s a risk you’re probably taking without realizing it.

Level 0 isn’t really a strategy. It’s just hope.

Level 1 - Uptime & Latency Monitoring

Level 1 is where monitoring actually begins.

At this level you automatically check whether your website is reachable and how long it takes to respond. A monitoring service such as Vigilant sends a request to your site at a fixed interval and verifies that it gets a successful response back.

This answers two fundamental questions:

If the check fails or the response time crosses a threshold, you get notified.

This already removes a huge blind spot compared to level 0. Instead of finding out from users or random manual checks, you’re alerted as soon as your website becomes unreachable.

However, it’s important to understand what uptime monitoring really measures and what it doesn’t.

An uptime check usually:

That means your server could be returning a 200 response while:

From the monitor’s perspective, everything looks fine.

Latency monitoring helps a bit by catching slow responses early. A site that takes 8 seconds to respond is technically “up”, but for users it might as well be broken.

Level 1 is essential. It gives you basic awareness and fast alerts when your site goes completely down or becomes very slow.

But it’s still a blunt instrument. It tells you that something is wrong, not what is wrong.

Level 1.5 - Worldwide Uptime & Latency Monitoring

Level 1.5 builds directly on basic uptime and latency monitoring, but fixes one of its biggest blind spots: location.

With standard uptime monitoring, all checks come from a single region. If your site works from that location, the monitor reports everything as healthy even if users elsewhere can’t reach your site at all. What’s even worse is monitoring from the same datacenter or server that your website is running on, the monitoring service will then never go over the internet!

At this level, the same uptime and latency checks are executed from multiple geographic locations around the world.

This helps answer new, very real questions:

This matters more often than people expect.

Problems that worldwide monitoring catches:

From your perspective everything might look fine. From a user in another continent, your site could be completely down.

Latency data becomes much more useful at this level as well. A response time of 300 ms in Europe might be 2.5 seconds in Asia. That’s not a backend issue, it’s an infrastructure and delivery problem you wouldn’t see from a single location.

Level 1.5 doesn’t add new types of checks, but it adds context. When an alert fires, you can immediately tell whether:

For websites with an international audience, level 1.5 isn’t a luxury. It’s the difference between thinking your site is healthy and knowing that your users can actually reach it.

Level 2 - Certificate Monitoring

At level 2, monitoring goes beyond availability and speed and starts covering security basics specifically, SSL/TLS certificates.

Every website that uses HTTPS (which should be all of them) relies on a certificate to encrypt traffic and prove identity. When a certificate expires or is misconfigured, users get scary browser warnings, which can instantly erode trust and probably stop them from visiting your site.

Certificate monitoring automates the task of keeping an eye on:

Without monitoring, you might only notice a certificate problem when a user reports a warning or your own browser blocks access. That’s reactive and by that time, your site’s reputation can already take a hit.

With certificate monitoring in place, you can:

Nowadays most renewals are automatic but automatic processes can fail causing your certificates to break. Better to prevent it.

Level 3 - Broken Link Monitoring

At level 3, monitoring starts to look inside your website instead of just at the front door.

Broken link monitoring works by crawling your website and following links, similar to how a search engine bot does. It checks whether the pages and resources your site points to actually return valid responses.

This helps you catch:

From an uptime monitor’s point of view, your site can be perfectly healthy while large parts of it are effectively broken for users.

A few common ways broken links appear:

For users, this creates friction and frustration. For search engines, it’s a quality signal. Too many broken links can hurt crawl efficiency and SEO performance.

Broken link monitoring turns this into a proactive process. Instead of stumbling upon issues months later, you get a report or alert when new errors appear.

This level shifts monitoring from “is my site up?” to “is my site usable?”

It’s also the first level where monitoring becomes comprehensive, because it touches many pages instead of a single URL.

Once you have this in place, the next logical step is not just whether pages load but how well they load.

Level 4 - Performance Monitoring

At level 4, monitoring focuses on how your website feels to users, not just whether pages return a response.

Performance monitoring measures things like:

A common way to do this is by running tools like Google Lighthouse on your pages at regular intervals.

This level catches issues that uptime and link checks completely miss:

Performance problems are dangerous because they don’t feel like “downtime.” Your site is up, links work, nothing is broken but users bounce, conversions drop, and SEO rankings slowly decline.

By monitoring performance over time, you get:

This also makes performance actionable. Instead of running Lighthouse once during development and forgetting about it, you treat performance as a living part of your site.

Level 5 - Synthetic Monitoring

Synthetic monitoring runs scripted user flows in real browsers. Instead of checking a single page, it simulates actions such as:

These flows are executed on a schedule, from start to finish, and every step is verified.

This level catches problems that all previous levels miss:

From the outside, your site can look perfectly healthy:

And yet, your core business flow is dead.

Synthetic monitoring gives you confidence in what actually matters: that users can complete the actions you depend on.

This used to be difficult for non technical people to setup as it required code to write the test cases. But with the rise of AI it is now possible to control a browser with English sentences. An example of that is Vigilant’s Flows feature allowing everyone to easily write and understand these flows.

Level 6 -Application Health Monitoring

Level 6 focuses on the internal health of your application, not just what’s visible from the outside.

Application health monitoring relies on health checks: dedicated endpoints or signals that report whether critical parts of your system are functioning correctly. Instead of asking “does this page load?”, you ask “is the application actually healthy?”

A proper health check can verify things like:

From the outside, your site might still return a 200 OK, while internally it’s already in trouble. For example:

Uptime monitors won’t catch this. Synthetic flows might not hit the affected path. Health checks surface these issues before they turn into user-facing failures.

Level 7 represents a mindset shift. Monitoring is no longer just observing outcomes, it’s observing system state. You gain confidence not only that your application works right now, but that it’s operating within safe boundaries.

With this level in place, monitoring becomes deeply tied to how your application is built and operated.

Level 7 - Security Monitoring

At level 7, monitoring shifts from availability and functionality to risk.

Security monitoring continuously checks your website and its dependencies for known vulnerabilities, misconfigurations, and exposures. This often includes scanning for:

The key difference at this level is intent. Everything before this level focuses on “is my site working?”
Security monitoring asks: “Is my site safe from attackers?”

Security issues rarely announce themselves. There’s no downtime, no broken page, no failed request. Your site keeps working until it doesn’t, or until data is leaked, defaced, or abused.

Without monitoring, you’re relying on:

With security monitoring, you get:

This level doesn’t replace proper security practices, but it adds a crucial feedback loop. It helps you move from reactive patching to proactive risk management.

Bonus: DNS Monitoring

DNS monitoring sits slightly outside the main levels, but it plays a critical supporting role.

DNS is the entry point to your website. If it breaks, nothing else matters, uptime checks, health checks, and synthetic tests all fail at once.

DNS monitoring focuses on observing your DNS records and detecting unexpected changes or resolution issues.

This includes:

DNS issues are surprisingly common and often hard to diagnose:

Without DNS monitoring, you usually find out the hard way when your entire site is unreachable for hours.

What makes DNS monitoring especially valuable is how quiet DNS failures are. There’s no error page from your application. There’s just… nothing. And if you’re unsure, it’s always DNS.

By monitoring DNS, you get:

DNS monitoring doesn’t replace other levels, but it reinforces all of them. It ensures that users can even reach the infrastructure you’ve worked so hard to protect.

Conclusion

Website monitoring isn’t a single tool or a checkbox you tick once. It’s a progression.

Each level adds a new layer of visibility: from basic uptime, to global reach, to performance, functionality, system health, and security. You don’t need to start at the highest level on day one, but you do need to be intentional about what you don’t see yet. Software like Vigilant do make it easy for you to reach all levels with minimal effort.

Monitoring turns unknown failures into known signals. It replaces guesswork with insight and reaction with prevention.

Great websites don’t just wor, they’re observed, understood, and cared for. Monitoring is how you get there.

Originally published at https://govigilant.io on March 19, 2026.

Self Hostable Multi-Location Uptime Monitoring

Vincent Boon — Sat, 15 Nov 2025 09:46:47 +0000

I’ve recently implemented the ability to monitor services from multiple locations in Vigilant. Vigilant is a open source and self hostable monitoring application that is made to monitor websites specifically. But the uptime monitoring works on any service.

Up until now the implementation of the uptime / latency monitor was simple, the main application sends a request to the service and stores the result. This means that when the main application has a slight network hiccup it will see the application as unavailable and send a notification. This is a false positive! Not what we want because when you check what’s wrong, you notice that nothing is wrong! These false positives are not acceptable and have to be prevented. How? By checking from multiple locations across the globe.

Requirements

I had a few requirements for this as I want to be able to purchase a cheap VPS via sites like lowendbox or lowendtalk and deploy quickly to these machines with minimal configuration. This allows me to setup multiple monitoring locations with a small budget. The ideal workflow would be to ssh into the machine, setup a docker compose file with an .env file and run it. The environment file would contain the URL to Vigilant. This requires the remote uptime containers to register themselves with the main application and this must be done in a secure way. Because Vigilant is open source and self hostable, I must also take into consideration the ease of setup for people who self-host Vigilant.

To summarize, the requirements for remote uptime monitoring in Vigilant are:

Able to run on random remote servers
Quick to setup using Docker
Automatic registering with Vigilant
Easy to use and understand for self-hosters

The Approach

My initial idea was to leverage the main application’s queue worker by deploying a queue worker remotely and setting up a secure connection between them using something like Wireguard. Vigilant is written in PHP using the Laravel framework, for queuing it uses Laravel Horizon. This is a queuing system built on top of Redis. All monitoring tasks in Vigilant are executed on this queue, it allows for multiple queues to exist identified by an unique name. Vigilant has queues for uptime, dns, lighthouse etc, this way the different monitors don’t block each other and resources can be managed per type of monitor.
To start a queue worker we can run a single command in a container, exactly like the horizon container does now in the current Docker compose setup.
So my first try was to deploy a remote Horizon worker that just handles one queue and name it something like uptime:de or uptime:us to specify the location. Horizon already runs in a separate Docker container.

I quickly realized that this will not work well, Horizon requires Redis and does not support multiple Redis servers. Redis is single threaded meaning only one operation at a time. With a VPN across the world the latency from the worker would block Redis for too long affecting the entire application.

So what about a proxy? Setup a socks5 proxy and run the checks via that? Well, first of all they aren’t auto-registering and Vigilant also requires latency information from the endpoint to the service which is not possible when using a proxy like this. We will have to write our own proxy to get the exact data we need.

I’ve done something similar for the Lighthouse checks, they run in a separate Docker container using a Go application. This app provides a HTTP server which Vigilant calls with the URL to run Lighthouse on. When it is done it will send the result back to Vigilant. Something similar for uptime would be good, send the request to this Go application but then directly return the response.

Why Go and not PHP? Vigilant is written in PHP so the obvious choice to write these external applications in would also be PHP, right? While PHP is great is does not for example have an inbuilt web server that supports multiple connections, the ability to schedule things on it’s own or to run things on startup. Other languages like Go and Python do which is why I choose not to write this in PHP. If written in PHP it would need a separate web server and a mechanism to detect when the container starts and stops to run a specific piece of code.

Building the outpost

I’ve decided to call these containers ‘outposts’ as they are remotely located from the main application.
These are the things that the outpost needs to do:

Self-registration
When the container starts, it immediately registers itself with Vigilant without requiring additional configuration.
Self-unregistration
Before shutting down (or when the container is stopped), the outpost sends a unregistration signal to remove itself from the active outpost list. This prevents stale entries or “ghost” outposts.
HTTP server for uptime checks
The outpost exposes a small HTTP API that Vigilant can call to perform checks.
Check execution
It supports both HTTP and Ping checks, measuring round-trip latency and returning the raw timing data back to Vigilant.

I’ve implemented these things into the Go application, once it starts up it will find it’s own public IP address and select a random port to listen to. It will then send those details to Vigilant and starts a HTTP server.
Via a Github action it is built into a Docker image and hosted on the Github container registry. The resulting docker compose file looks like this and is all that is required to setup an outpost:

services:
  outpost:
    image: ghcr.io/govigilant/vigilant-uptime-outpost:latest
    restart: always
    network_mode: host
    environment:
      - VIGILANT_URL=https://<Vigilant instance URL here>
      - OUTPOST_SECRET=<random secret string here>

You can view the source for the outpost here: https://github.com/govigilant/vigilant-uptime-outpost

Running uptime checks via outposts

Vigilant tracks which outposts are available and every time an uptime check it due it will select an outpost to run the check on. When an outpost registers itself, Vigilant will determine the lat/long and country code of the outpost.
The lat/long is then also determined for the monitored service to find the closest outpost. This is then used to ensure that most of the uptime checks are done from the closest outpost.

When a request to an outpost fails it will try another and mark that outpost as unavailable to prevent another process from using it. Then a background task periodically checks the unavailable outposts, removes them if they are unreachable or marks them as available when they work.

This also allows us to check from multiple locations when a service is down with a small tradeoff that the detection takes a bit longer due to the additional checks. When an outpost responds with the message that a service is down it will check two additional outposts to ensure this is really the case. The small time tradeoff is worth it here to reduce the amount of false positives.
For those who are interested, here is the source code for an uptime check.

Now that we also have a country per result we can incorporate that into the dashboard and notifications. When latency increases from a specific country Vigilant will now add that to the notification.

Securing the outposts

For security there are two concerns, how to prevent anyone from registering an outpost and how to ensure the communication from and to the outposts are encrypted.

Vigilant itself runs on HTTPS, at least it should (I can’t speak for self-hosted instances). But we consider the initial request from the outpost to Vigilant as secure because it goes over HTTPS with the secret token. To ensure we can trust the outpost, Vigilant and the outpost both have an API token. Vigilant sends the same key when running uptime checks, without this token you are unable to register an outpost or run an uptime check.

But the outposts start their own webserver on a random port and don’t have a certificate which causes the traffic to go via HTTP, not good. We need a way to run the outposts webserver on HTTPS. Should we setup DNS and use a reverse proxy to handle this? While that would be possible it goes against our minimal configuration principle. A self signed certificate then? Yes possible, but our main application wouldn’t be able to verify the certificate.

The first thing an outpost does is register itself, what if it gets a certificate from Vigilant? Vigilant can return a signed certificate which the outpost can use. Only Vigilant needs to be able to verify the certificate. This is exactly how I’ve implemented it, Vigilant acts as the root CA and generates 30 day valid certificates for an outpost. The outpost then starts a HTTPS server which causes the communication from Vigilant to the outposts to be encrypted.

The single point of failure

Outposts make it possible to monitor from multiple geographical regions but all requests are initiated from Vigilant, if Vigilant the application or the network it runs on becomes unavailable then no more checks are ran. This is not something that I want to get into now but I do monitor my monitoring service using Uptime Kuma.
But in order to solve this, Vigilant needs to run on multiple machines at the same time which is another layer of complexity where this project isn’t big enough for currently. Vigilant runs in Docker so something like Docker Swarm would be possible.

Multi-Location Monitoring for Self Hosters

When you host your own applications, for fun, privacy or to save costs it takes some effort to setup monitoring from different locations. Most self hostable monitoring tools only support a single location, you could place a monitoring application like the popular open source option Uptime Kuma on multiple servers but then you run into situations like location A is saying your service is down while location B says it’s up. Ideally you’d have one application which checks this but it really depends on your use case. For a homelab it is overkill but for a business it’s essential, I’m personally still running Uptime Kuma in my homelab but my other sites are monitored with Vigilant.

So to start monitoring from multiple location with Vigilant you can follow the multi location uptime monitoring guide in the documentation.

Vigilant now makes it possible to self host uptime monitoring from multiple locations but it requires managing multiple servers. As I’m attempting to make Vigilant self sustainable I also offer a hosted version for which I am setting up this infrastructure. I’m toying with the idea to make this accessible for self hosters by letting them connect to Vigilant’s hosted outpost for a small yearly price. That way you remain in control of your own data but do not have to worry about the worldwide infrastructure. I’d love to get feedback on this idea and/or hear if anyone is interested in this, please send me an email on vincent@govigilant.io and let’s chat!

Conclusion

Adding outposts to Vigilant not only solves the false positive issue but also opens the door to a more scalable and resilient architecture. With outposts, monitoring is no longer tied to a single server but it becomes distributed. The self-registering design keeps the setup experience simple for self-hosters (and for me hosting govigilant), while the secure certificate exchange ensures that communication remains trusted without requiring much configuration or DNS management.

Vigilant can now confidently say it doesn’t just monitor uptime; it verifies it from around the world.

Originally published at https://govigilant.io on November 15, 2025.

My SaaS homepage design journey as a backend developer

Vincent Boon — Thu, 06 Nov 2025 15:05:11 +0000

I’ve built Vigilant, a monitoring tool designed to monitor all aspects of your website. From basic uptime checks to more advanced checks like performance. user flows and public infrastructure. It started as an open source project and is now a SaaS using the open core structure.

As a backend developer, design is not my strongest point. In this article I’m sharing the different revisions of the homepage and the feedback I’ve got from generous internet users with which I was able to improve the homepage a few times to what it is now. I’ll share where I got the feedback and what I’ve changed.

I won’t make you scroll down the whole article to see the before/after, so here it is the initial version (January 2025) and (June 2025):

And now (November 2025):

The choice for dark mode

I had used a dark theme in one of my previous projects and decided that I wanted the same for Vigilant. Dark just has a cooler vibe to it in my opinion. I later learned that it is easier to make thing look nice on light mode, but I think I would still have made the choice for dark mode as it is my personal preference. Light mode would be cool to add in the future though. The color scheme I’m using is called Flexoki, which is open source and looks good in my opinion.

The Initial Version

The initial version of the homepage was simple. There were two colours, black and red, a list of features and a screenshot. The goal of this website was just to have something, the most important part was the stay updated e-mail input. The project wasn’t a SaaS at this point and if you wanted to use it you’d have to host it yourself (which is still possible today!).

This was fine when I started out, clean and simple but definitely not suitable for a SaaS homepage.

First redesign for SaaS

When I launched the SaaS version I wanted to make the homepage more appealing. I figured adding an animation would be cool, so I did. I’ve created this Lottie animation symbolizing how Vigilant works.
Dev.to doesn’t support lottie animations so you can view it on my original post: https://govigilant.io/articles/my-saas-homepage-design-journey-as-a-backend-developer

I had also changed the hero text to “Detect Website Issues Before They Cost You” and added the list of features in a bento grid with screenshots. Over time I’ve tried many different hero texts, I don’t remember all of them but have learned that there are many good options and it’s difficult to choose the right one 😅

Up until this point I’ve not had any feedback and it shows. Two colors, reused the same logo image multiple times and hard to read screenshots.

First feedback

I came across a post on Reddit where someone was offering to review landing pages. Ofcourse I commented Vigilant and he made a video looking at the homepage and sharing his thoughts.
He commented:

As independent buy says — it seems like a website built by a developer with in mind what they like. some work to do, but the tool itself has potential.

This of course motivated me greatly, the video can be found here, but I’ll here are his feedback points:

Design is rather simple but doesn’t look bad
Colors are missing
Animation is funny but not professional
CTA is too generic
Copywriting is about the product, should be about the customer.
Anwser these questions: For who is Vigilant and what does Vigilant solve?
Screenshot doesn’t tell anything
Use cases are missing

Around the same time I was chatting with another founder essentially told me the same, add more colors because there is no emotion now on the homepage. And the texts are about the product and not about the customer.

Applying the feedback

This feedback got me thinking. I started with the hero, I changed it to this and adjusted the text on the CTA button:

I went overboard with using colors in text, hoping that certain parts would stand out but in the end it was just too much.

I had created an image that had to explain how Vigilant’s flows feature works. I did so by arrows, small images and text. I thought that it was clear but after I looked at it a few hours later I noticed that it was actually very confusing. Would you understand this? No, you’d not waste your brainpower on this.

I had added colors, but just in the text. I’ve gotten feedback again on Reddit after making these changes which said that the red/green/blue were just too much and overwhelming. I also got the same feedback again, not enough color. It seems that I had failed in my mission to add color.

Adding color & animations

Instead of adding color on the page I changed the background color on some sections. Not too much, just a lighter base color from Flexoki but it looks much better like this in my opinion.

I removed the image with all the arrows for the Flows feature and replaced it with an animated GIF showing how it works. Because this is one of the most unique features of Vigilant I have made the background here blue so that it really stands out.

I had also added sections that highlight the notification channels and use cases.

To make it all a little nicer I added animations on three places. First of all the header, where I added moving stripes:

Then I added a little stripes animation to break up the page:

And finally I added little animated circles expanding behind the notifications, kind of simulating that you’re receiving a notification.

The final solution: AI

The current version of the homepage is drastically better than the first version, we learn and improve. It’s been a nice journey learning what to do and the feedback I’ve gotten from strangers on the internet has helped me enormously. I’d like to thank the people that took the time to comment and talk to me about the design, but realistically I know that they probably won’t read this.

Anyway, my design skills are skill mediocre so I experimented with AI. I used Copilot CLI and entered this prompt:

This statamic website has been designed by a backend developer that does not have any experience in design. It looks terrible, you are an expert designer and are improving the design of this website. You may alter the colors slightly. Let’s start by redesigning the homepage

And then I took it component for component and page by page through the AI. It looked much better and I even was able to add some nice face in animations and a cool hover effect on the hero.

In release 2025.11 I’ve also implemented this redesign in the application itself.

And that’s it! It has been a journey but I’m very satisfied with the result.

I’m always open for feedback, if you see something that could be better, please e-mail it to me at vincent@govigilant.io or join the Discord!

Originally published at https://govigilant.io on November 6, 2025.

Every Developer Should Try Vim

Vincent Boon — Thu, 19 Jun 2025 15:16:56 +0000

What is Vim?

Vim is a highly efficient, keyboard-driven text editor that prioritizes speed, precision, and control. It’s been around for decades, but it’s far from outdated. In recent years, Vim has seen a resurgence, thanks largely to Neovim, a modern refactor of Vim that brings a faster core, better plugin support, and a vibrant, forward-looking community.

Many developers avoid Vim because of its steep learning curve and unfamiliar interface. But that’s changing, as Vim’s community has grown rapidly. This shows that other developers are seeing Vim as a serious upgrade to their workflow. Of course, it can be said that these developers just don’t know how to quit Vim.
Luckily for us, someone has taken the time to compile a list of ways to exit Vim. I’ve ultimately chosen for The Acceptance Way.

You do not need to use Vim directly in your terminal, most modern editors have a Vim plugin so that you can keep using the editor you are familiar with and get the benefits of Vim. This saves you hours of configuration and makes the barrier to get started much lower.

Why use Vim?

Vim isn’t just an editor, it’s a mindset. I’ve started to use Vim because it offers unmatched speed, muscle-memory efficiency, and a sense of flow that’s hard to replicate. You’re no longer using your mouse or the arrow keys to navigate, you’re using your keyboard to go blazing fast.

At its core, Vim is a modal editor which is a little different than regular editors. It means you switch between modes and each mode has its own use cases. The modes in Vim are:

Normal mode — for moving around and making changes
Insert mode — for typing text
Visual mode — for selecting and manipulating blocks
Command mode — for things like saving, quitting, or searching

In a regular editor you would only have insert mode. This separation of concerns sounds odd at first, but it allows you to perform complex edits with just a few keystrokes. Once it clicks, it’s hard to go back.

Here are a few examples that show how Vim feels in action, these are all executed in normal mode:

Learning Vim is hard

I’ve personally struggled with learning Vim, it was intimidating at first. The reason for this is that modal editing was unfamiliar for me and I was so used to my previous JetBrains editor and its functions that I had a hard time being productive. I admit, the first time I tried it I gave up. To really get started learning Vim you have to change your mindset about how you write code, and that’s hard after all these years of programming.

I didn’t understand it well enough, I knew how to get into insert mode and use :wq to exit. With that little skill in Vim it feels cumbersome and slow to use. I hadn't even found out about Vimtutor, if you don't know, Vimtutor is a tool that teaches you the basics of Vim in about 20-30 minutes.

But there is a light at the end of the tunnel! As with any new skill, it’s only hard at the beginning. If you can push through the initial awkwardness, you unlock a tool that grows with you for the rest of your career. And you will be able to say: “I use Vim by the way”.

Start in your own editor

As I started learning more things about Vim using tools like Vimtutor and YouTube videos I decided that I would give it another go. Instead of using Neovim I installed Ideavim. This allowed me to get started with Vim in an environment that I was comfortable with. The first weeks were slow, I felt like my productivity had declined by 50%. But after that initial drop I noticed that I got faster, things started to feel natural and became muscle memory.

I no longer had to think about how to do something. My fingers just knew. That’s when Vim clicked for me, not as a tool I was forcing myself to use, but as an extension of how I write code. It really gives you an extra dimension of editing code.

Looking back, that short period of pain was more than worth it. Vim didn’t just change my editor, it changed how I like to write code. And that shift has made programming feel smoother, faster, and most importantly, a lot more fun.

The nice thing with Vim is that you keep learning, you keep finding ways to get faster. There is even a website called VimGolf that has challenges for users to do certain tasks with as few keystrokes as possible.

I stuck with my JetBrains editor and Ideavim for two years. After those two years I decided that I wanted to dig deeper, customize my editor more and really get the experience that I liked.

Switching to Neovim

The switch was hard at first, especially file management. I was so used to the file tree on the left of my editor. I tried to replicate that in Neovim with nvim-tree but it didn’t feel the same. Until I came across oil.nvim, this was a game changer for me as it made creating, renaming and moving so much easier. That was the moment that I felt I could switch. I had tried a few of the popular Neovim distros such as Lunarvim but found them too overwhelming.
I personally prefer a basic setup with not too many bells and whistles (I know, I used JetBrains before but only used 10% of that editor’s capacity and had a minimal interface configured).

I did not start with a blank Neovim install, I used kickstart.nvim. It has such clear documentation which made it really easy to understand and get started. This YouTube playlist by TJ DeVries also helped me a lot to get started.

It amazed me how limiting the JetBrains + Ideavim actually was, with Neovim it is so much easier to set up custom and more advanced keybinds using Lua.

Final Thoughts

Learning Vim isn’t just about picking up a new editor, it’s about changing how you interact with code. I believe that every developer should at least try Vim to see if it fits them. If you stick with it, Vim rewards you with a sense of control and fluency that’s hard to describe until you experience it yourself.

You don’t have to go all-in on day one. Start where you are. Use a plugin in your current editor, explore Vimtutor, or just commit to learning a few motions at a time. You’ll be amazed how much power you can unlock with just a handful of commands.

Vim won’t make you a better developer overnight, but it will change the way you think about writing code. And once it clicks, it becomes something you don’t want to work without.

Originally published at https://govigilant.io on June 19, 2025.

Why uptime monitoring isn’t enough for your website

Vincent Boon — Tue, 17 Jun 2025 18:20:40 +0000

Most uptime tools do the bare minimum: they ping your homepage every few minutes and look for a 200 OK response. If they get it, your site’s marked as “up.”

But here’s the problem: just because the homepage loads doesn’t mean the rest of your site is working. Your login could be broken. The checkout process might fail. An API endpoint might be silently throwing errors. Uptime checks won’t catch any of that, they only confirm that something responded.

I run Vigilant, an open-source website monitoring tool, so I wanted to share some insights based on what we’ve learned on monitoring websites.

You Do Need Uptime Monitoring

Don’t get me wrong, uptime monitoring is still important. You need to know if your site is reachable at all. If your server crashes or your hosting provider has issues, you want to be the first to know, not your users.

But the uptime monitoring service can also have connectivity issues, when that happens the service may give false positives. The only way to effectively combat this is if the uptime monitoring services use multiple locations to check if the site is down.

Most decent uptime tools also check latency, which gives you a sense of how responsive your site is over time. That’s useful. If response times start creeping up, it’s often an early sign something is wrong. Maybe a slow database query, maybe traffic spikes or high load on your server.

And don’t forget your SSL certificate. A broken cert blocks access and erodes trust. Monitoring tools should alert you before it expires.

Next-Level Monitoring

Once you’ve got basic uptime covered, the next step is to go deeper. Think of your site as more than just one page. It’s a system with moving parts, links, user flows, DNS, third-party services, and any of those can break without triggering a traditional uptime alert.

Broken links are a good example. They don’t take your whole site down, but they chip away at trust. Clicking into a 404 is frustrating for users, it’s a sign something in your website is broken.

Then there are key user flows. Logging in, signing up, resetting a password, placing an order, these are the things people actually come to your site to do. If one of those is broken, your site is technically up, but it’s failing its real job.

DNS is another layer most people don’t think about until it’s too late. If your nameservers go down or your domain is misconfigured, your whole site becomes unreachable, even if the server is fine. It’s like unplugging the sign from your storefront.

And finally performance, you need to know if a change on your website has a performance impact. Manually checking this with Google Lighthouse is time consuming and often forgotten.

Spotting Broken Links Before Your Users Do

Broken links can quickly frustrate users and harm your site’s reputation. Catching them early is key.

To find these you use a crawler. This is a tool that systematically clicks through your site, following every link it finds just like a user would. If the crawler hits a dead end, it flags the broken link.

Running a crawler regularly helps you catch problems before your users do. That means less frustration, better SEO, and a smoother experience overall. And because the crawler works automatically it saves you a lot of time by not having to manually check every link.

Monitoring Critical Flows, Not Just Pages

Synthetic monitoring isn’t new. It uses a real browser to simulate a user interacting with your site, logging in, checking out, filling forms to make sure those key flows actually work.

The tricky part used to be setting it up. You had to specify CSS selectors and element paths, which often broke when the UI changed. It was tedious and time-consuming to maintain.

Recently with the developments of AI, this is changing fast. Instead of wrestling with selectors, you can simply give instructions in plain English, like “click on the add to cart button” or “enter ‘Vincent Bean’ in the name input field”, and the AI figures out how to do it. That means less hassle setting up tests and more reliable synthetic monitoring.

Don’t overlook DNS

It’s always DNS. Most people think “set it and forget it”, and for many sites, that works fine. But there are exceptions you don’t want to miss.

For example, if you’re hosting a site but your client controls the DNS because it’s their domain, changes can happen without your knowledge. A simple tweak or mistake there can take your whole site offline for hours.

Even when you make DNS changes yourself, it’s helpful to get confirmation when those changes actually propagate. That way, you know roughly when the outside world will start seeing the update.

Always Patch in Time, Never Miss a CVE

When you’re running a website, especially a public one, security isn’t optional. The software you rely on can have vulnerabilities, known as CVEs, that malicious actors will try to exploit. If you have any experience hosting a site you will know that random bots try known exploits, just look at your access log.

When a CVE pops up for any software you’re using, you want to hear about it immediately so you can decide how fast to patch it. To be honest, most of the time, you should patch right away.

The tricky part is keeping track of these alerts. Relying on random news posts, Slack messages, or word of mouth is a bad idea. Critical CVEs need a reliable, automated way to find you by monitoring them.

Ensure Changes Don’t Affect Performance

Performance issues often slip in quietly, a new (improperly sized) image, a third-party script, a layout tweak, and suddenly your site is slower. The only way to catch this early is to track performance over time.

Running Google Lighthouse often is great for this. It audits your pages and gives you real metrics like First Contentful Paint, Time to Interactive, and more, all using a real web browser. When tracked over time, you get a clear picture of how changes are affecting the user experience.

Performance doesn’t just affect how fast your site feels, it impacts SEO, conversions, and user trust. So it’s worth watching closely.

Final Thoughts

Good websites don’t just work, they are cared for. But you can’t fix what you don’t know is broken.
That’s exactly why I built Vigilant. It’s designed to monitor your entire website, from uptime to user flows, DNS health to security vulnerabilities. Because keeping your site healthy means watching all the moving parts, not just the homepage.

You can self-host Vigilant for free, it’s open source software. Or you can try the hosted version for free.

Originally published at https://govigilant.io on June 17, 2025.

Getting my Laravel application security audited

Vincent Boon — Sun, 08 Jun 2025 17:48:35 +0000

A while ago I saw a message in a Slack channel that I’m in about someone that is building a tool to do security / code quality checks on PHP projects. He wanted a codebase to test his tool so I offered Vigilant.
I’ve received a detailed report on the code quality and security of Vigilant, in this post I’ll share the report.

Vigilant is an open source web monitoring application written in PHP using the Laravel framework. It uses the latest PHP and Laravel version and minimizes dependencies. It has been a core design decision to minimize the amount of third party packages for Vigilant to prevent dependency hell. “This choice has also improved security-less external code means fewer potential abandoned dependencies and more control at the cost of some extra work. When I do add an external dependency I have a few requirements such as code quality, activeness and downloads.

Let’s get into the security audit, each blockquote is a copy/paste from the report and not something I’ve typed myself.

Summary and Methodology

The report starts with an executive summary which comes with an issue chart and conclusion.

performed a source code review on the source code repository vigilant. The objective of the review was to identify code quality and security issues in the source code. A total of eight issues were identified during the review. Each issue was rated according to its severity: one was rated as low severity, and seven as informational.

Conclusions
The code review found one low-severity security issue in the codebase. This issue should be addressed to ensure the security of the application.

The overall quality of the codebase is good, but we have identified a few opportunities to improve the quality and maintainability of the code.

Overall, the codebase is in good shape.

The next page contains recommendations in which they say that there is no guarantee that there aren’t any security vulnerabilities.

Recommendations

We recommend addressing the issues identified in this report as part of regular development activities. The severity of the issues should be taken into account when prioritizing the fixes.

While the review identified some issues, it is important to note that this assessment does not guarantee the absence of other security vulnerabilities in the application. It is recommended to perform regular security assessments to ensure the application remains secure.

After these two introductory pages the report starts by describing the application and how the audit was performed.

The vigilant application is written in PHP (13.2 KLOC) and JavaScript (97 LOC) and uses the Laravel framework.

Scope

The source code review was performed against the code found in https://github.com/govigilant/vigilant.

We focused on the parts of the application written in PHP. Source code written in other languages was not reviewed.

Methodology

The source code review was performed by analyzing the vigilant source code repository using static code analysis tools. The findings were then manually reviewed to ensure their accuracy and relevance. The code review focused on the following areas:

One of the most interesting parts I found was a list of tools they used, this means that I could integrate these tools in a pipeline to automate some of these checks.

The following tools were used to perform the source code review:

What are the findings?

There are a total of eight issues identified, one of them was low severity and seven were informational.

Docker image runs as root

The only low severity finding was that the docker image runs as root. I found it really nice that they provide the impact, recommendation and references to understand the issue.

Missing strict_types declaration

The second finding is that all the PHP files are missing the strict_types declaration. This is not really an issue since I’m running PHPStan in Github actions to check for type errors.

Commented-out code

Here you instantly notice that the tool isn’t made specifically for Laravel, it complains about comments in configuration files. It did find two places where commented code existed but then other 24 cases were configuration files.

Unresolved TODO comments

Here is a valid point in my opinion, the codebase should not contain any TODO comments. They are only acceptable if there is an action planned to resolve them, such as a story on the backlog.

Error suppression with the @ operator

Vigilant has a built-in crawler which reads HTML, sometimes HTML can be malformed which is why I’ve chosen to use the @ operator. This was a conscious decision and I’ve included a comment why it was added.

High cyclomatic complexity

It’s nice that the tool checks this but you do not always have control over how it must be implemented. For example, their first finding in the table needs to be implemented a certain way because that package requires it like that.

Short commit messages

Vigilant is currently only developed by me which made me not really pay attention to the commit messages. I’ve since changed this by adding new code via pull requests with a clear description.

No healthcheck defined in Dockerfile

I’ve added health checks in the docker compose, but not in the Dockerfile as the image is intended to only run via compose. I’m using the same image for the web container and the queue container so I’d need multi-stage builds to add separate health checks which are not my priority right now. It would be a good addition.

My feedback on the tool

As this audit was done for free I was asked to provide feedback on the findings which I gladly did.

First of all I agree with the strict types finding but I would like to have seen a note that the files are being checked by PHPStan. Also, the commented out code for Laravel projects in the config directory findings can be omitted.

In the list of tools was Trivy, it would have been nice to have somewhere mentioned that the CVE’s have been scanned and none matched.

Finally I’ve suggested that some checks on composer dependencies should be added, for example if there are low quality or abandoned external packages in the project I would like to know. The tool should also run its checks on these dependencies to get an idea of the quality.
A package that has a few hundred downloads is much less reliable than a package that has thousands of downloads on Packagist as the chance of a high quality fork is higher when the original author decides to stop development.

Final Thoughts

I’m happy that there aren’t serious issues in Vigilant’s source code, it was interesting to see what things are checked and how. This review confirmed the value of key design decisions like limiting dependencies.

If you found this interesting, please consider starring the repository 🙏

Originally published at https://govigilant.io on June 8, 2025.

Architecture of my open source Laravel monitoring application

Vincent Boon — Wed, 04 Jun 2025 18:50:31 +0000

I’ve built this project using the Laravel Framework, I am familiar with the ecosystem and it contains everything I need to build a web monitoring application. Most importantly it has Horizon, a powerful queueing system.
For the interface I’m using Livewire and Eloquent’s global scopes ensure that users do not see each other’s resources.
It is also easy to dockerize for self-hosting utilizing Laravel Octane so that I don’t have to deal with Nginx and FPM.

But a project with many different components also comes with a challenge, how to keep the codebase clean and organized? By default Laravel ships with an app folder in which your models, controllers, and other logic go. This default structure works initially, but quickly becomes overwhelming as the application grows. Each component has models, jobs, and actions so I have a lot of different classes.
We could create folders for each component but that will still be a lot in one place.
The solution for me is to utilize the power of Composer.

The Power of Composer

If you have worked on any modern PHP application you probably know Composer. It is the most popular package manager for PHP. Laravel also heavily utilizes Composer and there are a lot of Composer packages available for Laravel.

One of the key architectural decisions in Vigilant is treating each major feature as a standalone Composer package. To wire them all together, I use Composer’s path repository feature. This is what that looks like in the composer json of the Laravel application:

"repositories": [    {
        "type": "path",
        "url": "./packages/*"
    },

Then I add all the packages using Composer’s @dev alias:

    "require": {
        "vigilant/certificates": "@dev",
        "vigilant/core": "@dev",
        "vigilant/crawler": "@dev",
        "vigilant/cve": "@dev",
        "vigilant/dns": "@dev",
        "vigilant/frontend": "@dev",
        "vigilant/lighthouse": "@dev",
        "vigilant/notifications": "@dev",
        "vigilant/onboarding": "@dev",
        "vigilant/settings": "@dev",
        "vigilant/sites": "@dev",
        "vigilant/uptime": "@dev",
        "vigilant/users": "@dev"
    },

By structuring your code into independent packages, you naturally promote separation of concerns. Each feature becomes isolated. Models, migrations, jobs, and logic all live together, making your codebase easier maintain and you instantly know in what folder you need to look when you want to find a file.

It also makes it easier to write isolated tests and reduce accidental coupling as the dependencies of the package’s composer json are required.

What’s inside a package?

Each of the packages contains the following:

The packages themselves are responsible for registering the things that they need such as migrations, routes, commands, and Livewire components. The main project does not force or expect any of these.

Let’s take a look at the certificates package, this package contains all of the logic for Vigilant’s certificate monitoring. The composer json located in packages/certificates/composer.json looks like this:

{
    "name": "vigilant/certificates",
    "description": "Vigilant Certificate Monitor",
    "type": "package",
    "license": "AGPL",
    "require": {
        "php": "^8.3",
        "guzzlehttp/guzzle": "^7.8",
        "laravel/framework": "^12.0",
        "livewire/livewire": "^3.4",
        "vigilant/core": "@dev",
        "vigilant/sites": "@dev",
        "vigilant/users": "@dev",
        "vigilant/frontend": "@dev",
        "vigilant/notifications": "@dev"
    },
    "require-dev": {
        "laravel/pint": "^1.6",
        "larastan/larastan": "^3.0",
        "orchestra/testbench": "^10.0",
        "phpstan/phpstan-mockery": "^2.0",
        "phpunit/phpunit": "^11.0"
    },
    "autoload": {
        "psr-4": {
            "Vigilant\\Certificates\\": "src"
        }
    },
    "autoload-dev": {
        "psr-4": {
            "Vigilant\\Certificates\\Tests\\": "tests"
        }
    },
    "extra": {
        "laravel": {
            "providers": [                "Vigilant\\Certificates\\ServiceProvider"
            ]
        }
    },
    "scripts": {
        "test": "phpunit",
        "analyse": "phpstan",
        "style": "pint --test",
        "quality": [            "@test",
            "@analyse"
        ]
    },
    "minimum-stability": "dev",
    "prefer-stable": true,
    "repositories": [        {
            "type": "path",
            "url": "../*"
        }
    ]
}

As you can see the package name is vigilant/certificates which is how the main composer json requires it. Then in the require list of this package are the other packages it depends on. For example, the certificate monitor needs to send notifications so it depends on vigilant/notifications to do that.

The service provider is set up just like any other Laravel Composer package, it registers routes, configuration, migrations, views, policies/gates, and Livewire components.

But it does not only register the things Laravel needs, it also registers things Vigilant needs. For example, it registers the menu in the file packages/certificates/resources/navigation.php:

<?php
use Vigilant\Core\Facades\Navigation;
Navigation::add(route('certificates'), 'Certificates')
    ->icon('phosphor-certificate')
    ->gate('use-certificates')
    ->routeIs('certificate*')
    ->sort(600);

And it registers notifications with their conditions for the notification system:

NotificationRegistry::registerNotification([    CertificateExpiresInDaysNotification::class,
    CertificateExpiredNotification::class,
]);
NotificationRegistry::registerCondition(CertificateExpiresInDaysNotification::class, [    SiteCondition::class,    
    DaysCondition::class,
]);

This way each package is responsible for adding to the main application.

Quality checks

I just quickly want to mention quality checks (tests, PHPStan, code style), these are done per package and if you have looked closely at the composer.json of the certificates package you have seen that it contains a composer command called quality.
This way each package is responsible for which quality checks run.

All these quality checks are run per package in a GitHub workflow using a matrix which makes them all run in parallel, this is a really cool feature that GitHub has. And the best thing is that it creates the matrix automatically using a ls command in the packages folder. Check out the GitHub action here.

How to handle common logic and views?

Common logic is put in a special package called the core. The core contains things like validation rules, global scopes, and policies but also middleware and some utility classes.

Frontend lives in two places, the layout is in the main project and the common components are in a package called frontend. Each package that has frontend requires vigilant/frontend and uses these components.

The only exception is the scheduler, packages themselves do not register their scheduler. Instead this is handled in the main application so that we can quickly see what commands are being scheduled without having to jump through multiple service providers.

But Vigilant is also a SaaS

Vigilant is an open-source project at heart but also has a SaaS component, this is the hosted version of the application. In this version I need things like billing, policies, and an admin panel.
I have chosen to not publish these as open-source software to make it harder for people to create their own SaaS with my code. I think the benefits of open-source software outweigh the risks but I must keep this part closed source to mitigate some of that risk.

These additional things I need for the SaaS are packaged in a separate SaaS repository. This repository is like the packages folder in the main project, it contains multiple packages that all register themselves.

During the build process of the SaaS version, it will do a composer require on the SaaS package which adds all the necessary packages.

But as you can imagine the SaaS version has some different requirements, I’m using Laravel’s policies and gates to control resource limits but as you might know, if you check if someone may create a model and don’t have a policy for that model it will always return false. Vigilant has a setting in the configuration called edition. This is ce (Community Edition) by default. There is a global helper function to check if it is running in ce mode, this is what the service providers use to add an allow all policy to the models. The SaaS version does not run in the ce version and the SaaS package brings it’s own policies for all the models.

Final Thoughts

Building Vigilant as a modular Laravel application has been a rewarding architectural decision. By leveraging Composer’s path repository feature, each part of the system, from certificates to the SaaS packages, is neatly encapsulated into its own package. This has made the codebase more organized, maintainable, and scalable as the project continues to grow.

Laravel’s ecosystem, combined with tools like Livewire, Horizon, and Octane, provides everything needed to build a modern web application. But Laravel’s real power shines when you break away from the monolithic default structure and start thinking in terms of domains and components.

Modularity doesn’t just help with code clarity, it also enables faster testing, clearer ownership of features, and an easier path to open-sourcing or scaling into SaaS. While managing multiple packages adds some overhead, the long-term benefits in code quality and team collaboration far outweigh the costs.

If you found this helpful, please consider starring the repository 🙏

Originally published at https://govigilant.io on June 4, 2025.

My Laravel Horizon preferences after 5 years of using it

Vincent Boon — Thu, 29 May 2025 20:04:24 +0000

When working with Laravel Horizon, it’s easy to get started, run php artisan horizon, dispatch some jobs, monitor them in the dashboard, and you’re good to go. But as your application scales and the amount of jobs grow more complex, subtle issues begin to surface. The design of your jobs and configuration of Horizon and Redis must be correct in order to run Horizon without issues.

I've been working with Laravel Horizon for the past five years on Laravel applications that do 1M+ jobs per day. In this article, I’ll share what I’ve learned from working with Laravel Horizon for five years. Including how I prefer to design jobs; how I isolate queues to prevent bottlenecks; and most importantly, the hidden pitfalls of Horizon's configuration and how to avoid them. If you’ve ever had a job mysteriously fail to dispatch or vanish without explanation, read this article.

I've added a few code examples from my open source project, Vigilant. An all-in-one website monitoring application.

Designing Jobs: Slim, small and quick

I prefer to keep my jobs slim, the job class should be responsible for how it runs on the queue and not running the actual logic of the action. I usually decouple the logic in seperate action class. Decoupling the logic from your job provides a few advantages, first of all your logic is not dependent on a job and can be called from anywhere. This is good practice as it makes your code more flexible. For example, if you later decide that you need the same code in a controller it is better to call a separate class with your logic than dispatching your job synchronously. Dispatching a job synchronously defeats the purpose of putting your code in a job anyway.

Let's take a look at one of Vigilant's jobs, the CheckUptimeJob. As you can guess this job is responsible for checking if a service is up.

<?php

namespace Vigilant\Uptime\Jobs;

use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldBeUnique;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;
use Vigilant\Core\Services\TeamService;
use Vigilant\Uptime\Actions\CheckUptime;
use Vigilant\Uptime\Models\Monitor;

class CheckUptimeJob implements ShouldBeUnique, ShouldQueue
{
    use Dispatchable;
    use InteractsWithQueue;
    use Queueable;
    use SerializesModels;

    public function __construct(public Monitor $monitor)
    {
        $this->onQueue(config('uptime.queue'));
    }

    public function handle(CheckUptime $uptime, TeamService $teamService): void
    {
        $teamService->setTeamById($this->monitor->team_id);
        $uptime->check($this->monitor);
    }

    public function uniqueId(): int
    {
        return $this->monitor->id;
    }
}

As you can see, the handle method only sets the environment and calls the action. The constructor just accepts the properties it needs to run and it defines an unique id. All the jobs in Vigilant are written like this, they are just a way of running logic on the queue.

I have also found that more jobs that have little runtime are better than a single job that does a lot and takes a while to complete. For example, when there are 100 sites that Vigilant needs to check the uptime for it will dispatch 100 jobs instead of one job that checks all the sites. This has a few benefits, first of all you can utilize Horizon's multiple processes per queue running the jobs in parallel.

But the greatest benefit of running small jobs is error handling. When a job fails you know exactly with what arguments the job was ran (if you set the right tags!). That way it will be easier to find the cause of the failure. You can even implement the failed method and add extra logging to your Eloquent model for example. That way you'll always know when something went wrong and what the exception was.

Queue configuration: Isolate workloads

Deciding on what queues to have, how many processes to allocate and how to configure them is heavily dependent on your application. If you do not have many different jobs a single queue is fine. As you scale you'll notice that you'll need to split them up so that unrelated processes don't block each other.

For Vigilant I've chosen to separate the queues by the type of monitor. This way a web crawler cannot block an uptime monitor. These two types of monitor also have very different requirements. Uptime monitoring is strict and must run at a specified interval. That means that there always should be a worker available to pick up a job.

When crawling a website it is not a problem if a job is waiting in the queue for a few minutes, as long as it gets run.

Unique Jobs: Misconfiguration will cause them to never run

Unique jobs are great for ensuring that a job is never dispatched twice, but when misconfigured it can cause strange issues such as your job not dispatching. Most jobs in Vigilant are unique, for example, the uptime monitor dispatches a job at a specified interval but if for any reason the job hasn't executed within that interval I do not want another job on the queue.

Unique jobs work by storing an unique lock key in your cache, as long as that key exist a new job will not be dispatched. Normally the key gets created when the job is dispatched and removed when a job finishes. It does not matter if your job completes successfully or fails, the lock will always be removed.

I've written a whole article about this in the past, you can check it out here.

Job timeouts

When you've worked with Horizon you'll probably recognize the job timeout exceeded exception. I just want to highlight two configuration entires that you should configure based on your slowest job.

First of all the timeout setting in your Horizon queue worker which can be found in config/horizon.php.

Secondly Laravel's config/queue.php contains the retry_after setting which you should configure at the same value.

Redis configuration for Horizon

As Horizon is built on Redis you cannot skip this configuration. There are two settings that are important:

maxmemory
maxmemory-policy

The maxmemory option should be obvious, Redis should have enough memory to store your jobs. But the more important option of the two is the policy. What should Redis do if the memory is full? These are the options:

# volatile-lru -> Evict using approximated LRU, only keys with an expire set.
# allkeys-lru -> Evict any key using approximated LRU.
# volatile-lfu -> Evict using approximated LFU, only keys with an expire set.
# allkeys-lfu -> Evict any key using approximated LFU.
# volatile-random -> Remove a random key having an expire set.
# allkeys-random -> Remove a random key, any key.
# volatile-ttl -> Remove the key with the nearest expire time (minor TTL)
# noeviction -> Don't evict anything, just return an error on write operations.

When working with jobs we never want to remove any. All jobs that are pushed onto the queue should be picked up by Horizon. With this knowledge the only way we can guarantee that all jobs will be picked up is by setting the policy to noeviction. This means that the part of your application that dispatches the job will get an exception when Redis is full. This is preferable as the alternative is that a random job will be removed and with an exception you get alerted when Redis is full.

While the no eviction policy is the best for queues, it's not the best for cache. This is why I always run two Redis instances, one for the queue and one for cache.

Monitoring Horizon beyond the basics

Horizon's default dashboarding is lacking, it shows the basic information but not enough when you start running a large amount of jobs. It is possible to expand the monitoring of Horizon because Horizon and Laravel's queueing system provide a few events that you can hook into. You can also query the Redis database to gain specific insights.

In the past I've written an alternative dashboard for Horizon which I've since have abandoned in favour of Prometheus / Grafana. I've found that collecting metrics and publishing them to Prometheus is far superior than storing them in a MySQL database. I do not have any open source code for this way monitoring but here are a few ideas which are possible:

Export all pending, completed and failed jobs over time so that you get a historic overview of what runs when and how long large processes take.

Keep track of job runtimes to get an idea which jobs are the slowest and can be optimized.

Count the unique jobs and unique locks to check for differences.

As Horizon is built on Redis it is also important to monitor Redis, especially the memory and maxmemory usage.

Final Thoughts

After five years of working with Laravel Horizon, my biggest takeaway is this: Horizon is incredibly powerful—but only if you treat it with care and intention.

Many of the issues developers face with Horizon aren’t bugs, it is usually incorrect configuration.

Whether it's isolating queues to prevent bottlenecks, understanding how unique job locks work under the hood, or fine-tuning Redis configuraiton to avoid deleted jobs.

The strategies I’ve shared, from designing slim, single-responsibility jobs to building out advanced monitoring with Prometheus have helped me build reliable, observable, and maintainable queue systems. If you're just starting with Horizon or you're troubleshooting mysterious job behavior, I hope this post helps you avoid some of the sharp edges I’ve encountered along the way.

Thanks for reading, feel free to dig into Vigilant if you’re curious how these patterns look in a real world app.

How I plan on scaling my Laravel (PHP) application

Vincent Boon — Wed, 22 Jan 2025 17:44:58 +0000

I am building 10MPage.com which captures the state of the internet in 2025. Every internet user is allowed to upload a small image of 64x64 pixels and contribute to this archive. That means you too! ;)

As a solo developer I want to spend as little money as possible in the early stages of this project which is why I host on a cheap VPS.
But I do want to be prepared for what comes next, when this project grows I need to have a plan on scaling the hosting of this application.

The application and the services it requires

The application is written in PHP using the Laravel framework and currently hosted on a single machine. The application heavily relies on background processes for handling the images, finding free places on the grid to place new images and sending e-mails.

The background processes are run through Laravel Horizon which is a queueing system that uses a long lived PHP process. This is running via supervisor to ensure that it is automatically restarted when it stops. Each deployment of the application the process will stop and be restarted by supervisor.

All jobs and caching are done with Redis and the data is stored in a MySQL database. Web requests are served through nginx using PHP-FPM.
The current setup looks like this:

I am aware that there are services like Laravel Forge but they require an extra subscription which is more that my single server costs. For this reason I am setting everything up myself on a simple VPS.

Scaling up

The first and most simple way to scale up is to upgrade the VPS to a bigger machine. This can be done within a few minutes and has some downtime. But it's a good way to buy some time if scaling is needed due to high load to setup other servers.

To scale even more I need seperate servers. I'd like to do this with as little downtime as possible so here's my plan in (count) steps:

Move Redis to a seperate server
Add a load balancer
Create new worker server(s)
Add webservers
Old webserver becomes the new database server

Step one, Redis

Downtime: None

I'd start with moving Redis to another server. The web appliction can be configured to temporarily use the local file system for caching and the job queue can be temporarily shut down. I'd setup a new server and add it to a private network. I am not bothering with clustering Redis as Laravel Horizon does not support Redis clusters.
After Redis is moved we can turn it off and uninstall it on our original server.

At this point I'd have two servers, one Redis server and one web/database/worker server handling the rest.

Step two, load balancer

Downtime: None

In order to load balance across multiple web server we first need a load balancer. I've got experience with HAProxy so that is what I'll be using. It has a little more options than nginx for load balancing such as active health checks and more load algorithms.
This server will also handle SSL termination.

For this second step I will still be running the web server on our first server. After this load balancer is setup I will change the DNS to point to this server.

At this point the setup has three servers, one Redis server, a load balancer and our first server still handling the web requests, workers and database.

Step three, seperate worker servers

Downtime: None

As I explained before, the background worker is essential for running this project. It needs to talk to Redis and the database to do it's work and can be turned of for a little while. The application is designed so that it will always start off where it was last left. This is done by using states, for example a pending tile can have the state 'place' so that the worker knows that it must place that tile. After placement the status will change.

Laravel Horizon is also designed to run on multiple servers, that means that I do not have to shut down the current worker when adding a new one. The process of seperating this to another server is straightforward. We create a new server, deploy and configure the application and use supervisor to run the worker.

After that we can shutdown the worker on the original server. Scaling workers is as easy as replicating a worker server.

Step four, multiple webservers

Downtime: None

We've already added a load balancer, to seperate the webservers we can follow the same steps as the worker server. But instead of running Horizon with supervisor the server will serve the application via HTTP using nginx and FPM. Also here, when we've got one server we can simply replicate it. The only configuration that has to be done is adding the webservers to the load balancer.

At this point we have a single redis server, a single database server, a single loadbalancer, seperate worker servers and seperate web servers.

Set five, single database server

Downtime: Few minutes

The original server now has only one function, the database. In order to keep it clean I will remove any other software that is not required on this server. Nginx, supervisor, redis and PHP can all go away. As the database server is one of the most important parts of the application I need it to have enough capacity. Clustering is an option but also a lot of work. I think that one big DB server is fine for this project but that does come with a cost. Scaling up will require a server reboot during which the application does not work.

And there we have it, all five steps of my scaling plan for 10MPage. Here are all te steps visualized:

Application deployments

Deployments have to be adjusted, initially there was only one place where the app had to go. But with multiple servers running the application (web and worker servers) it now must be deployed to all of them.

I am using git based deployments, I have a small script included in the repository that deploys the application. For a single setup it does all steps but with seperate servers it must do a few checks to know what to deploy. For example, I can run php artisan horizon:status to see if Horizon is running and only restrt it when it is. I can do the same for PHP-FPM.

The only adjustment is that it needs to run on multiple servers. I will create a simple script that triggers this on all of the servers.

Single point of failure

I am aware that this setup has multiple single points of failure.
The points of failure are:

Single load balancer
Single database server
Single Redis server

The next step in this setup would be to eliminate some single points of failure. The load balancer can be setup redundant on two servers with a floating IP, so when one fails the floating IP can be switched to the other node.

The database and redis server are another story, if I need to scale those up I will write a follow up article on that. But I do not expect it happen.

A note on containers / clusters

I'm a big fan of running applications in containers and the scalability of them is great. But for smaller projects like this I believe that it is overkill to containerize the application and deploy it on a cluster. I'm keeping the hosting setup simple to that I can set it up as quickly as possible in the initial phase of the project. I do not see it needing things like autoscaling. The only reason for using containers in this project would be the ease of setup when scaling to multiple servers. But since this project does not require much I decided that I'd rather make snapshots and clone machines when I need to scale

Conclusion

Scaling 10MPage.com is an exciting challenge that I approach with a pragmatic mindset, keeping the infrastructure simple yet effective. Starting with a minimal setup on a single VPS allows for cost efficiency in the early stages, while the outlined scaling plan ensures a smooth transition as the project grows. Each step, from moving Redis to a separate server to implementing a load balancer, adding workers, and deploying multiple web servers, is designed to minimize downtime and maintain the application’s functionality.

By keeping the hosting straightforward and avoiding the complexities of containerization or clusters, I can focus on building the project and adapting as needs evolve. This deliberate approach balances preparation with simplicity, ensuring 10MPage.com remains robust, scalable, and aligned with its mission to capture the essence of the internet in 2025—one tile at a time.

Thank you for reading this artile, I hope you've learned something.
If you did, why not add your favorite programming language, crypto coin or your pet to the 10MPage? It is free!