DEV Community: Nicolas Beauvais

Recreating Laravel Cloud’s range input with native HTML

Nicolas Beauvais — Wed, 02 Jul 2025 15:27:54 +0000

For the past few days, I’ve been working on improving the billing experience in Phare, with the addition of prepaid credits. While tweaking the billing UI, I realized the current input for configuring additional quota wasn’t great, it didn’t clearly show what was already included in the paid plan versus what the user could add.

The UX of entering large number in a text input could certainly be improved. It wasn't horrible, but I felt it could be better.

So I went hunting for inspiration on Dribbble, and other listing websites that post screenshots of SaaS services interfaces. After some research, I stumbled upon the Laravel Cloud pricing calculator. Their range input design was spot-on: clear separation between included and additional values, visually appealing, and user-friendly.

Naturally, I did what any self-respecting developer would do, open the browser inspector to ~~steal~~ look at the code. Turns out, they recreated a full range input with a few HTML elements and glued everything with JavaScript using Alpine.js. Here's the structure:

<div class="group/range relative h-8 self-stretch">
  <!– Full track -->
  <div />

  <!-- Static track -->
  <div />

  <!-- Progress bar -->
  <div />

  <!-- Handle -->
  <div>
    <div>
      <span></span>
    </div>
  </div>

  <!-- Tick -->
  <div />

  <!-- HTML range input -->
  <input />
</div>

Because I'm the laziest developer, rebuilding all this for the six people (love you guys 🫶) that pay for Phare felt like overkill. Could I recreate a similar input with less work? There's probably a way to get a similar result with some CSS on top of the native range input, and maybe a few lines of JavaScript.

Building the range input

To match the Laravel Cloud design, we need the following components:

Range track : the rail where the handle moves.

Handle : the draggable thumb.

Progress bar : the filled area left of the handle.

Static part : a fixed section showing the value already included in the plan.

Tick : a visual marker where the included value ends and extra begins.

The static part and tick are mostly cosmetic and can easily be visually faked outside the range input itself. Everything else is already included in the native HTML range input.

So why did the Laravel team go full custom?

Limitations of the native HTML range input

To look great, the handle needs to land exactly at the tick’s position when at the minimum value. It should also cover the tick to be visually appealing:

Unfortunately, this isn't possible as the native range input’s handle is confined to the boundaries of the track. So, what if we make the range input track overlap under the static part to allow the handle to sit on the tick? (such a weird sentence).

Well, the native range inputs don’t let us set a different z-index for the handle and for the track. If we push the track behind the static part, the handle goes with it. If you bring it forward, the whole thing looks messy.

The solution

Enter the CSS inner shadow : using an inner shadow allows us to fake a few extra pixels of the static part inside the track. This lets the handle glide over it without getting hidden.

By carefully layering the tick and the static track visually outside the actual input, and using this inner shadow to fake part of the static part, we can get something that works well.

Styling the handle

Using the border property on the handle with -moz-range-thumb work great in Firefox, but Chrome does not seem to support it. Again, inner shadows are here to save the day, and bring us cross browser consistency.

Styling the progress bar

To make the progress bar pattern, Laravel's team used a clever trick based on repeating-linear-gradient to create infinitely repeating stripes.

background-image: repeating-linear-gradient(135deg, black 0px, black 1px, #99a1af 1px, #99a1af 4px);

But applying that to our native range input will cover the entire track. I only wanted it on the left side of the handle to represent progress.

For fixing this, there isn't any other solution, we will need a few lines of JavaScript:

document.getElementById("range").addEventListener('input', function (event) {
    let input = event.target
    let value = parseInt(input.value)
    let min = parseInt(input.getAttribute('min'))
    let max = parseInt(input.getAttribute('max'))

    let percentage = (value - min) / (max - min) * 100

    input.style.backgroundSize = `${percentage}% 100%, 100% 100%`
})

Final result

The end result is not quite as flexible as Laravel Cloud’s full custom implementation. Since the track should fake the design of the static part and tick, it does not allow more complex design, but it fits perfectly for my use case:

Conclusion

The final native HTML approach is quite simple, with minimal tricks, and still good-looking. I think it shows that it's possible to go quite far with native elements without having to resort to recreating everything with JavaScript.

You can see a fully working example and the code to recreate the input on CodePen:

And if you like my attention to details, you should try Phare, it's a great tool for uptime monitoring, incident management, and status pages.

What to look for in an uptime monitoring tool

Nicolas Beauvais — Mon, 16 Jun 2025 20:43:51 +0000

If your website is how you pay the bills, whether it’s a SaaS, an API, or that side project financing your daily ramen, you need to know when it’s down. Preferably before your customers start angrily spamming that F5 key.

There are thousands of uptime monitoring tools out there, but after running one myself for a few years, here’s what I think you should actually be paying for.

Pick a tool that won’t sleep on the job

There’s no point in using an uptime monitoring service that’s less reliable than the thing you’re monitoring.

I love indie products (obviously), but this is one of those times where time in the market beats timing the market*.

Check how long the tool’s been around
Carefully review stats on their status page, some are... enlightening
Check out the documentation, it’s usually a good indicator of quality
Most reviews online are fake, ask your friends instead

*Not financial advice.

Cloud or self-hosted? Choose wisely

Your monitoring system should live outside your infrastructure, spread across multiple data centers, poking your endpoints from different parts of the world. That’s typically not something you get with a self-hosted setup.

That said, self-hosted might make sense if:

You’re monitoring a closed/private network
You’ve got confidential credentials involved
You like the smell of YAML in the morning

If you go the DIY route, open-source projects like Kener and OpenStatus give you slick status pages and great features while being easy to host.

Otherwise, uptime monitoring being a brutally competitive market, good cloud options are often cheaper than spinning up a new VPS, with the benefit of not having to spend time on maintenance.

Pricing that won’t eat your runway

Some tools charge by tiers, others charge by usage. Both can be good, but you do need to know how far your plan will take you.

Keep an eye out for:

Surprise features locked behind expensive plans, like SSO
Pricing jumps that increase your monthly plan by 600% to monitor that one additional endpoint
Per-seat costs (gets expensive fast if you grow)
Extra costs for things like API monitoring, fancy assertions, or exotic check types

If you’re planning to grow, plan for growth. Otherwise, a cheap starter plan could turn into a budget black hole real quick.

Fast and silent checks

Short intervals of 1 minute to 30 seconds are great, but the increased false positive alerts are not. Make sure your monitoring service confirms failures before it blows up your phone in the middle of the night. Good providers give you:

Failure confirmation
Recovery confirmation
Options to tune how aggressive or chill your alerts are

I wrote a whole guide about this if you want the nerdy details: Best practices to configure an uptime monitoring service

Check from around the world

Just because your site work in Paris does not mean it works in Singapore. Routing is weird. DNS is weird. Internet infrastructure is insanely complex, and sometimes fragile.

If your users are global, your monitoring should be too, especially if you’re doing edge deployments or running multi-region setups.

More than just up and down

“Up or down” is just the start. Depending on what you’re building, you’ll want your uptime tool to handle:

API checks with custom payloads
SSL certificate monitoring (inventory, validity, expiration, AIA, OCSP)
DNS validation
Performance & response times
Tracing & diagnostic info
Custom assertions (e.g., make sure that PHP version header is not present in production)

OhDear is a great example that offers an extensive list of extra checks, like SEO monitoring or broken link and mixed content detection.

Solo today, team tomorrow

Right now you might be a team of one (hey friend 👋), but good monitoring tools support teams, shared dashboards, incident timelines, etc.

Even solo founders need to sleep occasionally. Having a friend or colleague see the same alerts is a life upgrade worth investing in early on.

Plays nice with your stack

Your monitoring tool should work with whatever communication channels you already use, no matter if you’re a Slack, Email, or Webhook person. Alerts should come to you, and not the other way around.

Also keep an eye for generic integration like incoming and outgoing webhooks as well as APIs. They will provide you with ways of integrating a third party or custom-made solution as you grow.

Good logs save bad days

When things break, you need as many details as possible:

The actual HTTP status code
The full response body
Headers
DNS resolution steps
Request trace

You could even go further with traceroute logging or screenshot capture. Most cloud solutions provide this. If you’re going self-hosted, you can rig something with webhooks and a great screenshot API like CaptureKit.

It’ll save you hours writing postmortems, debugging edge cases, or explaining to your users why everything went sideways last Thursday.

TL;DR

Pick a tool you can trust
Make sure it’s got the features you need today and tomorrow
Choose something that helps you fix problems, not just point at them

I’m building Phare.io with this mindset, check it out if you’re looking for a great uptime monitoring tool with incident management and status pages. It’s free to start and scales with your needs.

The 3-Year Journey to an Actually Good Monitoring Stack

Nicolas Beauvais — Tue, 15 Apr 2025 19:34:35 +0000

When I started building Phare in early 2022, I planned the architecture assuming that fetching websites to perform uptime checks would be the main scaling bottleneck, and oh boy, was I wrong. While scaling that part is challenging, this assumption led to suboptimal architectural choices that I had to carry for the past three years.

Of course, when you build an uptime monitoring service, the last thing you want is your monitoring infrastructure to be inefficient, or worse, inaccurate. Maintenance and planning take priority over everything else, and your product stops evolving. You're no longer building a fast-paced side project, you're just babysitting a web crawler.

It took a lot of work to fix things while maintaining the best possible service for the hundreds of users relying on it. But it was worth it, and the future is now brighter than ever for Phare.io.

Let’s go back to an afternoon in the summer of 2022, when I said to myself:

Fuck it, I’m going to make an uptime monitoring tool and compete with the 2,000 that already exist. It should only take a weekend to build anyway.

(It was probably in French in my head, but you get the idea).

The very first version: Python on AWS Lambda

AWS Lambda immediately felt like a perfect fit. I had written a few Lambda functions before, and it seemed like a good choice to easily run code in multiple regions, with the major benefit of no upfront costs and no maintenance. Compared to setting up multiple VPSs, with provisioning and maintenance on top, the choice was clear.

I wrote the Python code for the Lambda, and all that was left was to invoke it in all required regions from my PHP backend whenever I needed to run an uptime check.

The AWS SDK supports parallel invocation, which solved the problem of data reconciliation. I had the results of all regions in a single array and could easily decide if a monitor was up or down, sweet.

$results = Utils::unwrap([
  $lambdaClient->invokeAsync('eu-central-1', $payload),
  $lambdaClient->invokeAsync('us-east-1', $payload),
  $lambdaClient->invokeAsync('ap-south-2', $payload),
]);

Most of the business logic was built on top of that result set. How many regions are returning errors? How many consecutive errors does this particular monitor have? Is an incident already in progress? Should the user be notified? etc. (As you guessed, this becomes important later.)

This setup worked well, delivering accurate and reliable uptime monitoring to the early adopters of Phare, while I focused on building incident management and status pages.

Until May of 2024, when I received a ~25 euro invoice from AWS. Okay, that’s not much, but that was for only 4M performed checks. That’s the cost of five entry-level VPSs, all to monitor about 100 websites. Not cost efficient at all.

I might have created the most expensive uptime monitoring service

The biggest part of the spending was from Lambda duration (GB-Seconds). As Phare’s user base grew, websites got more complex, no more just monitoring my friends’ single-page portfolios with 100 out of 100 Lighthouse scores. Websites can be slow, and even with a 5-second timeout, the Lambda execution ended up being far too expensive.

Another issue was request timing accuracy. AWS Lambda lets you select the memory limit from 128MB to 10GB, and with more memory comes more CPU power. To fetch a URL with realistic browser-like timing, the Lambda needed at least 512MB of memory, a significant cost factor for longer checks, and a huge financial attack vector.

It was time to find an alternative.

Enter Cloudflare Workers

Cloudflare Workers seemed unreal, much cheaper than AWS Lambda, and you only pay for actual CPU time. That meant all the idle time waiting for timeouts was now completely free. I could build the cheapest uptime monitoring service while keeping a good margin, and offer an unbeatable 180 regions.

Setting it up wasn’t straightforward. On top of having to rewrite the code in JavaScript, it was not possible to invoke a Worker in a specific region. And that was a major blocker.

After many failed attempts, I came across a post from another Cloudflare user who had figured out how to do exactly that, using a first Worker to invoke another one in a chosen region. It wasn’t documented, but Cloudflare seemed aware of this loophole for a while, with no public plan to restrict it. The performance and pricing were too good to ignore, so I went with it. YOLO.

The two-Workers technique changed everything. I could send large payloads of monitors, have the first Worker create smaller regional batches, and return reconciled results. My backend became more and more dependent to the way Cloudflare Workers behaved.

Of course, there were limitations: non-secure HTTP checks were a no no, it was impossible to get details on SSL certificate errors, and TCP port access was restricted. But I managed to find a few workarounds, and everything was running smoothly.

The ecosystem was growing fast, edge databases and integrated queues were being released by Cloudflare, my workers averaged sub 3ms execution times. The future looked bright.

Of course, after just a few months, on November 14th, 2024, regional invocation was patched, and the entire uptime infrastructure went down. That day was a looong day.

I quickly patched the script, rerouting all requests to the invoking region so uptime checks still ran, even if not in the right region.

It was time to find an alternative. Fast.

Bunny.net Edge Scripts to the rescue

At that time, Bunny.net had just released their Edge Scripts service in closed beta, a direct competitor to Cloudflare Workers, built on Deno. Pricing was similar, and the migration looked plug-and-play, which was all that mattered, because I couldn’t afford the time to rewrite the backend logic.

I got into the beta, rewrote the script in Deno using the same two-invocation strategy, and began rerouting traffic from Cloudflare to Bunny.

The first part of the migration went smoothly, regional monitoring was back up, and I could finally relax a bit.

Of course it wasn't long until shit hits the fan, and the uptime monitoring performance data started to get funky. Cloudflare was a more mature solution that handled many things in the background, like keeping TCP pools in an healthy state, which is important when you perform thousands of requests to different domains.

Thankfully, Bunny’s technical team was amazing. They helped me a lot, and I gave them plenty to work on in return.

Eventually, things got better. Edge Scripts left beta and became generally available, and that’s when a new bottleneck appeared.

The backend code was still invoking Edge Scripts and waiting for a batched response. As Phare gained new users daily, the number of invocations grew. My backend started hitting 502/503 errors on Bunny’s side. Queue wait times forced me to increase concurrency. And I was still facing the same limitations I previously had with Cloudflare Workers.

Maybe Edge Scripts weren’t the best long-term solution after all.

I knew what I had to do from the beginning: decouple the backend from the edge scripts and process results asynchronously. But doing so meant reworking the deepest, most fundamental part of my backend logic, now massive after years of accumulated features.

Again, I had no choice if I wanted to keep improving Phare.

It was time to find an alternative.

The obvious answer: Bunny Magic Containers

In early 2025, Bunny announced Magic Containers, a new service letting you deploy full Docker containers across Bunny’s global network. I had been desperately trying to find a European hosting provider with such a diverse range of locations. I was already integrated with the Bunny ecosystem, and had full confidence in their amazing support team.

This time, I did things slowly. I built a few preview regions to test at scale with real users, in parallel with the still-working Edge Script setup. Of course this meant running two versions of the backend logic at the same time, two different ways of triggering monitoring checks, and thousands of new line of code to make it work. Not fun, but necessary to finally fix the past mistakes.

The new uptime monitoring agent would run continuously in a Docker container, billed by CPU and memory usage. Cost was a major concern, so I rebuilt it in Go with the following goals:

The Phare backend and the monitoring agent must be fully decoupled.
The agent should fetch its monitor list from an API, no backend push.
Results are sent asynchronously to the backend.
Data exchange should be minimal.
The agent must be fault-tolerant and self-healing.
It should match the feature set of the Edge Script version.

And just like that, six new preview regions were added to Phare at the end of February, and they ran like fine clockwork. I actually went on vacation a few days after the release, for a full month, and didn’t have a single issue. I did have a lot of time to reflect on my past mistakes.

I won’t go into too much detail about the new infrastructure, this post is painfully long enough already. Today, all checks run on Bunny Magic Containers. And for the first time in years, I can focus on building new features for both, the agent, and the platform.

And if I ever need to change provider again, I can just spin up a few VPSs with my Docker image and it’ll work. I should’ve done that from the beginning, but I wanted to go fast, and that costed me a few years of real progress.

What’s next

The current infrastructure works well, but it’s not perfect. When a container is restarted there's a brief overlap where two instances might run the same check. If a region goes offline, there’s no re-routing, users need to monitor from at least two regions to stay safe.

Fetching the monitor list every minute via API works surprisingly well, thanks to ETags and a two-tier cache system. But I’m still exploring how to reduce HTTP calls. Having read replicas closer to the containers might be the best bet.

From the outside, it didn’t look so bad, Phare grew to nearly a thousand users during all this infra chaos. Users loved the quality of the service far more than I did.

This post is mostly a rant at my past self. I took too many shortcuts while building what started as a weekend project, which held the company back once it grew beyond that. But maybe that’s what startups are all about.

That said… see you in three years for the blog post about Phare.io Monitoring Stack v8, probably rewritten in Rust, because history repeats itself.

Best practices to configure an uptime monitoring service

Nicolas Beauvais — Mon, 26 Aug 2024 16:00:22 +0000

Getting alerted of downtime is an essential part of running a healthy website. It's a problem that got solved a long time ago by uptime monitoring services, but as simple as setting up a monitoring service for your website might seem, there are a few best practices that I learned other the years maintaining dozens of websites from side-projects to Fortune 500, and building Phare.io, my own take on uptime monitoring.

We will dive into some best practices to get the best possible monitoring without false positives, the configurations explored in the article should work with most monitoring services.

Choosing the Right URLs to Monitor

Defining which resources to monitor is the first step to a successful uptime monitoring strategy, and as simple as it might seem, there some thinking to do here.

The first thing to consider is how your website is hosted. Many modern startups will have landing pages on a static hosting provider like Vercel or Netlify, and a backend API hosted on a cloud provider like AWS or GCP. Then you might have external services hosted on a subdomain like a blog, a status page, a changelog, etc. Each of these resources can go down independently, and you should monitor them separately.

🎓 Find all resources that can independently go down and monitor them separately.

For each of these resources, you need to define the right URL to monitor, and there are again a few things to consider:

Static hosting

Most statically hosted websites will use some form of caching through a CDN. If you monitor a URL cached at the CDN level, you might not get alerted when the origin server is down. You then need to check with your monitoring service or your CDN for a way to bypass the cache layer.

🎓 Make sure you monitor the origin server and not a cached version of your website.

Dynamic websites

For dynamic websites or API endpoints, it's tempting to monitor a simple health check route that returns a static JSON response, but you might miss issues that are only visible when hitting API endpoints that do some actual work.

Ideally, the URL that you monitor should at least perform a database query, or execute any critical resources of your application to make sure everything is working as expected. Creating a dedicated URL for monitoring is usually a good idea.

🎓 Monitor an endpoint that performs actual work and not just a static health check.

External services

Monitoring external services is usually not as important as you are not responsible for their uptime. However, it's always good to be proactive and get alerted before your users do. This will allow you to communicate about the issues and show that you are on top of things.

🎓 Monitor external services to be proactive and communicate about issues before your users do.

Redirections

Now you should have a good idea of the urls you need to monitor, you need to check for any redirections. Be careful with the URL format that you use to monitor your resources, some services will end all URLs with a / and some won't, you will put an unnecessary load on your server if you don't use the right format and will likely get wrong performance metrics on your uptime monitoring service.

🎓 Be mindful of unnecessary URL redirection to avoid load on your server and inaccurate performance metrics.

Monitoring that a few critical redirections work as expected is also a good idea, things like www to non-www, or http to https redirections are critical for your website SEO and user experience and could be monitored.

🎓 Monitor critical redirections to make sure they work as expected.

Response monitoring

Now that you have defined the right URLs to monitor, you need to define the excepted result of your monitors. In the case of HTTP checks, that will usually be a status code or a keyword on the page.

It is common knowledge among web developers that status codes are not always to be trusted, and that a 200 OK status code doesn't mean that the page is working as expected. This is why it's a good idea to also monitor for the presence of a keyword on the page.

A good keyword is something unique to the page that would not be present on any error page. For example, if you choose the name of your website, there's a high chance that it will also be present on a 4xx error page, and you will get false positives monitoring for it.

🎓 Always check the response status and the presence of a unique keyword on the page.

Request timeout

Finding the right timeout for your monitors is a true balancing act. You want to make sure that the timeout is not too wide to avoid any false positives, but you also want to make sure that it's not too short to get alerted when your server is too slow to respond.

My advice is to start with a large timeout for a few days and then gradually decrease it until you find the right balance. Of course this should be done on a per-url basis, as some resources might be naturally slower than others.

Some monitoring services will have special configurations for performance monitoring that you could use for this purpose, you should also keep in mind that services will calculate response time differently, and you might get different results from different services, so it's always a good idea to start with a large timeout.

🎓 Start with a large timeout and gradually decrease it until you find the right balance.

Monitoring frequency

The monitoring frequency is another balancing act. You want to make sure that you get alerted as soon as possible when your website goes down, but without wasting resources on unnecessary checks for your website that is up 99.99% of the time and for our beautiful planet.

Choose shorter intervals for critical resources and longer intervals for less important things like third-party services or redirections. You could also consider the time of day and monitor more aggressively during your business peak hours.

Keep in mind the following when choosing the monitoring frequency:

Every 30 seconds = ~90k requests per month
Every 1 minute = ~45k requests per month
Every 5 minutes = ~9k requests per month

🎓 Choose shorter intervals for critical resources and longer intervals for less important things.

Incident confirmations

I would strongly advise against using any monitoring service that does not offer a way to configure a number of confirmations before sending an alert. This is, with multi-region monitoring the most impactful way to avoid false positives.

The internet is a complex system, and a single network glitch could prevent your monitoring service from reaching your server. It might not seem like a big deal, but the more alert you get, the more you will ignore them, and you will certainly miss a real incident after a few weeks of receiving daily false positives alerts.

This setting should be configured based on your monitoring frequency, and the criticality of the resource you are monitoring. The more frequent the monitoring, the more confirmations you should require before sending an alert, here is a good rule of thumb:

30 seconds monitoring interval -> 2 to 3 confirmations
1 minute monitoring interval -> 2 to 3 confirmations
2 to 10 minutes monitoring interval -> 2 confirmations
Any greater monitoring interval -> 1 to 2 confirmations

🎓 Always require a confirmation before sending an alert.

Multi-region monitoring

Just like incident confirmations, multi-region monitoring is a must-have feature for any monitoring service. It often happens that a request fails temporarily from a specific monitoring endpoint, but it doesn't mean that your website is down.

When checking from multiple regions, uptime monitoring services will usually require a certain number of regions to fail before sending an alert. This is a great way to avoid false positives and make sure that your website is really down for your users.

You should always monitor all resources from at least 2 regions, and more for critical resources. When possible, choose the regions closest to your users this will give you the best results and accurate performance metrics.

🎓 Monitor all resources from at least 2 regions.

Alerting

The last thing to consider is how you want to be alerted. Most monitoring services will offer a wide range of alerting options, from email to SMS, to Slack or Discord notifications.

As we previously established, not all resources are equally important, and you might want to be alerted differently for each of them. Think about the way your company communicates, and how you could integrate the alerts into your existing workflow. You might want to create a dedicated channel for alerts, or use a dedicated email address for alerts. For the most critical resources, you might want to use SMS or Phone notifications, but discuss this topic with your team and make sure that everyone is on the same page. If you configure SMS alerts and the on-call person keeps a phone on silent, that might not be the best idea.

🎓 Choose the alerting method adapted to each resource and discuss this topic with your team.

Conclusion

In most cases uptime monitoring is a set and forget kind of thing, but I've seen many teams struggle with false positives and alerts fatigue. By following these best practices, you should be able to get the best possible monitoring without false positives, and make sure that you are alerted when your website is really down.

If you are looking for an uptime monitoring service that helps you implement these best practices, you should check out Phare.io. It's free to start and scale with your needs.

How we run Ghost on Docker with subdirectory routing

Nicolas Beauvais — Thu, 22 Aug 2024 17:00:17 +0000

Deciding on the right blog platform is always a bit of a hassle, whether it's for my personal blog or my company. I often have to resist the urge to build something from scratch, which inevitably means sinking the next two weeks into coding yet another blog from the ground up.

When it came to setting up a blog for Phare.io, I made a conscious effort to minimize the time spent on setup. After some research, I decided on Ghost, a well-regarded content platform that seemed to meet all our needs. Self-hosting looked straightforward, and the documentation mentioned support for subdirectory routing, which was a key requirement for our SEO strategy.

But as is often the case, things weren't quite as simple as they first appeared. Hence, this blog post to guide anyone looking to do something similar.

Setting Up Ghost on Docker

To keep things organized, the plan was to isolate Ghost on its own server. For this, I spun up a new VPS instance on Hetzner running a Docker-CE image.

This instance runs on a private network without a public IP, and the firewall is configured to accept traffic only from Phare's NGINX server on port 8080.

This setup might be a bit over the top for hosting a blog, but it was quick to implement and significantly reduces the attack surface, so there’s no reason not to do it.

With the server ready, the next step was to write a Docker Compose file to configure Ghost's Docker image on port 8080 along with a MySQL database:

services:
  ghost:
    image: ghost:5-alpine
    restart: always
    ports:
      - 8080:2368
    environment:
      database__client: mysql
      database __connection__ host: db
      database __connection__ user: root
      database __connection__ password: {{ ghost_db_password }}
      database __connection__ database: ghost
      mail__transport: smtp
      mail __options__ host: {{ ghost_mail_host }}
      mail __options__ port: {{ ghost_mail_port }}
      mail __options__ auth__user: {{ ghost_mail_user }}
      mail __options__ auth__pass: {{ ghost_mail_password }}
      mail __options__ secure: true
      url: https://phare.io/blog
    volumes:
      - ghost:/var/lib/ghost/content

  db:
    image: mysql:8.0
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: {{ ghost_db_password }}
    volumes:
      - db:/var/lib/mysql

volumes:
  ghost:
  db:

Here are some key points to note in that file:

The ghost service binds to port 8080, which is the one we opened on the firewall.
Both services use persistent storage, making backups straightforward.
The url environment variable should be set to the public URL where your blog will be hosted.

Once the configuration is complete, you can start the services with Docker Compose:

docker compose up

In our case this step is automated with an Ansible playbook task:

- name:
  community.docker.docker_compose_v2:
    project_src: /docker/ghost
    files:
      - docker-compose-ghost.yml
    state: present

And just like that, we have a running Ghost instance.

Configuring Subdirectory Routing with NGINX

Phare.io uses an NGINX server to manage load balancing, headers, and a few other tasks. Our setup involves complex routing to allow users to create status pages on *.status.phare.io or their own domains.

For the blog, we wanted it to be accessible only on our main phare.io domain, so the first step was to adjust our configuration to ensure only phare.io was served, excluding any subdomains.

With that in place, I created a location block to route all /blog traffic to the Ghost instance:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;

    server_name phare.io;

    # location / {
        # Configuration for our Laravel app
    # }

    location ^~ /blog {
        client_max_body_size 10G;

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://10.0.1.2:8080;
    }

    location ~* \.(jpg|jpeg|webp|png|svg|gif|ico|css|js|eot|ttf|woff)$ {
        gzip on;
        expires 1M;
        access_log off;
        add_header Cache-Control public;
    }
}

I removed a few irrelevant lines, here are the important details:

As recommended by the Ghost documentation, set a high client_max_body_size to allow large file uploads via the Ghost admin panel.
The ^~ directive in the location block ensures no other location block takes precedence, which is crucial to prevent interference with the caching rules further down that could break asset loading.
The proxy_pass directive points to our Docker server's private IP 10.0.1.2 and the previously opened port 8080.

Accessing the blog

With everything set up, the blog is now accessible at phare.io/blog, and the admin panel at phare.io/blog/ghost. Our Ghost Docker instance runs securely on a private network.

To speed up asset loading and caching, we use bunny.net on the phare.io domain. Most of our existing rules worked seamlessly on the blog, but I hit a snag when Ghost couldn’t create a session cookie, preventing me from signing in.

The problem was that cookies were disabled on the domain. Changing this setting solved the issue without affecting the rest of the site, as Phare only uses session cookies on the app.phare.io domain. However, a potential improvement could be moving Ghost's admin panel to its own subdomain, which would allow this setting to be re-enabled.

Conclusion

Hosting a Ghost blog on a /blog subdirectory path using NGINX is a practical solution when you want to seamlessly integrate your blog with your main website. While it requires some configuration, the benefits for SEO and branding make the effort worthwhile.

I hope this post helps you in setting up your own Ghost blog. The Phare team is delighted with the platform so far, and I’m glad I didn’t spend weeks building a half-baked in-house solution.

Would you like to make sure your blog or any other part of your website stays online? Create a Phare account for free and start monitoring your website today.

Downsampling time series data

Nicolas Beauvais — Mon, 29 Jul 2024 09:50:00 +0000

At Phare uptime we allow you to view your monitor's performance data with up to 90 days of history. While this might not seem like a lot, a monitor running every minute will span about 130 thousand data points during that time frame, for a single region.

Showing that amount of data in a graph would be slow and impossible to understand due to the sheer number of data points. Finding the best solution requires the right balance between user experience, data quality, and performance. We need to tell you the story of your monitor's performance in a way that is easy to understand, fast, and accurate.

In this article, we dive into a few techniques that we used to downsample the data by 99.4% while keeping the most important information.

Raw data

We start with the raw data collected from monitoring the Phare.io dashboard in the last 90 days. The performance varied a lot during this time frame thanks to a noisy CPU neighbor, which made it the perfect candidate for this article.

If we plot the raw data with 130 thousand points, we get a chart that looks like this:

The performance is not terrible, loading the data takes about 230ms, and rendering the chart is done under 100ms, which is already better than a lot of other charts out there. But the real problem is that the chart is unreadable, we can't see any patterns, and it's hard to understand what's going on.

The confusion does not only come from the number of data points but also from the scale difference in the data. The vast majority of the requests will be performed under 200ms, but about 0.1% of them will be slower. It does not matter how fast your website and our monitoring infrastructure are, there will always be a few requests that will be slower due to network latency, congestion, or other factors.

Removing anomalies

Our first step is to remove the anomalies from our data set. A single 4-second request among a few thousand will skew the data and make it hard to read. We need to remove these anomalies in a way that will keep any sustained decline in performance visible.

To solve this problem, we can use one of two techniques:

Standard deviation: We can calculate the standard deviation of the dataset and remove any data points that are outside a certain multiple of the standard deviation.
Percentile: We can calculate the 99th percentile of the data set and remove any data points that are above that value.

Both solutions offer similar results, but need to be applied on a rolling window to make sure that we don't remove any sustained decline in performance and keep anomalies in periods of high performance.

We use the formula rolling mean + (3 x rolling standard deviation) to remove any data points that are three standard deviations above the rolling mean, and chose a rolling window of 30 (15 points before and after the current point):

By zooming in on the few remaining spikes, we can see that they are not isolated anomalies but sustained periods of lower performance which we want to keep in our data set.

The following is a zoomed-in view of the tallest spike on the right, we can see that the spike is followed by a series of slower requests over 1h30, this is exactly the kind of information we want to keep:

If we did not calculate the deviation or quantile in a rolling window, we would get the following chart, which removes everything above 600ms while keeping many anomalies in the lower performance range:

Rolling window average

The next step is to smooth the data with a rolling window average. This technique will slightly reduce the gap between two adjacent data points and make the chart more readable while allowing us to detect trends in the data.

For this example, we use a rolling window of 10 data points (5 points before and after the current point) to smooth the curve without losing too much information:

Downsampling

Our data is now clean and smooth, but we still have 130 thousand data points to display which cost bandwidth and rendering performance. To reduce the number of data points without losing too much information, we can use the largest triangle three buckets (LTTB) algorithm.

The LTTB algorithm is a downsampling technique that finds the most important points in the data set by dividing the data into buckets and selecting the point with the largest triangle area in each bucket. In simpler words, the algorithm will only keep the points that are the most representative of the data set so that the overall shape of the curve is preserved.

By applying the LTTB algorithm to our data set, we can reduce the number of data points from 130 thousand to 750, which is a reduction of almost 99.5%. In the form of a JSON payload, we go from 1.53 MB to 13 KB, which is a significant reduction in bandwidth.

As you can see, the chart looks almost identical to the full data set, but uses only a fraction of the data points.

It is important to carefully prepare the data before applying the LTTB algorithm, as the algorithm is specifically designed to preserve the overall shape of the curve it will keep any anomalies into the final data set.

Implementation with ClickHouse

ClickHouse is a powerful column-oriented database optimized for analytical queries that offers unparalleled performance for time series data. We extensively use it at Phare to store and analyze the performance data of your monitors.

All the techniques described in this article can be implemented in a single ClickHouse query using the largestTriangleThreeBuckets function, as well as window functions.

-- Apply the LTTB algorithm to the data set
SELECT
  largestTriangleThreeBuckets(750)(
    `cleaned_results`.`timestamp`,
    `cleaned_results`.`time`
  )
FROM
  (
    -- Smooth the remaining data with a rolling window average
    SELECT
      `raw_results`.`timestamp`,
      avg(`raw_results`.`time`) OVER (
          ROWS BETWEEN 5 PRECEDING AND 5 FOLLOWING
      ) AS `time`
    FROM
      (
        -- Select the raw data
        SELECT
          `timestamp`,
          `time`,
          -- Calculate the rolling window average and standard deviation
          avg(`time`) OVER (
              ORDER BY `timestamp` ROWS BETWEEN 15 PRECEDING AND 15 FOLLOWING
          ) + 3 * stddevSamp(`time`) OVER (
            ORDER BY `timestamp` ROWS BETWEEN 15 PRECEDING AND 15 FOLLOWING
          ) AS anomalies
        FROM
          `performance_table`
      ) AS `raw_results`
    -- Filter out anomalies
    WHERE
      `raw_results`.`time` < `raw_results`.`anomalies`
) AS `cleaned_results`

Drawing the data

Phare uses uPlot to draw charts in the frontend. uPlot is a small, fast, and flexible charting library, which perfectly fits our needs. It allows us to draw charts with a large number of data points with the best possible performance, where other libraries would struggle.

Keep in mind that uPlot is a low-level library, which means that you will need to spend a good amount of time configuring it to get the desired result. But the performance and flexibility it offers are worth the effort.

Because we already processed the data with ClickHouse, we only need to separate the data in two arrays, one for the x-axis and one for the y-axis, and pass them to uPlot.

new uPlot(options, [
  timestamps, // x-axis values
  times // y-axis values
], document.body);

Of course, Phare implementation is more complex than that, we need to handle responsive, live-streaming, and displaying uptime incidents, but this goes beyond the scope of this article.

Conclusion

By removing anomalies, smoothing the data with a rolling window average, and downsampling the data with the LTTB algorithm, we were able to reduce the amount of data by 99.4% while keeping the most important information.

The chart is now readable, fast to load, and easy to understand.

Would you like to see this performance chart for your own website? Sign up for free and start monitoring your website today.

Deploy Laravel on Railway

Nicolas Beauvais — Thu, 04 Aug 2022 13:43:09 +0000

In this article, I will show you how to properly deploy a Laravel project on Railway, an infrastructure platform that handle all the system administration and DevOps tasks for you.

Making Laravel work on Railway is easy enough, but there are a few catches that deserve a thorough explanation. Unless you want to spend an entire day browsing the internet like I did to search for nonexistent explanations, perks of being an early adopter!

One of Railway characteristic is that every time a deployment occurs, your project server is rebuilt with your new code, which mean that everything stored on the file system is erased.

If you're not familiar with PHP deployment on horizontally scaled architecture or blue-green deployment, we will cover all the configuration tweaks that you need to do to make your Laravel project work properly.

1. First deployment

Railway deployments are based on Nixpacks, an open source tool (developed by the Railway team) that read your project source code and create a compatible image where it can run.

On a standard Laravel project, Nixpacks will set up nginx to handle requests, PHP with your project's required version, NodeJS with your favorite package manager Yarn, pnpm or npm.

Creating a project is straightforward, just head to Railway.app/new, set up your account, and choose the repository to deploy.

If you gave Railway access to a GitHub repository, you automatically got push-to-deploy setup, pretty nice.

Your project is now deploying, the build step should work fine, but you won't be able to visit your landing page because Laravel need a few environment variables to run.

You can paste the content of your .env file in the raw editor with the values you would like for production.

We can also tell Nixpacks to add a few dependencies when building our project with the NIXPACKS_PKGS env variable, like PHP Redis to communicate with a Redis server, and PHP GD to work with images file.

You can search for available packages here to make sure you get the syntax right.

A new deployment will automatically start to rebuild your project with the provided environment variables.

By default, your project will not be publicly accessible, you can head to the settings panel and generate a Railway subdomain with SSL, or follow instructions to use your own domain.

2. Database creation

Because the file system is reset on every deployment, using a local database like SQLite is not possible. No worries, Railway offers MySQL, PostgreSQL, MongoDB and Redis.

In your Railway project, click on the new button, and choose your favorite database management system.

Once created, you will be able to retrieve the credentials in the Variables panel.

You can copy these values in your Laravel project environment variable to give your code access to the database.

A new deployment will automatically rebuild your project with the provided environment variables and give your code access to the database. Keep in mind the database does not yet contain any table as we did not run Laravel's migration.

3. Redis

No persistent file system means that the default Laravel drivers for cache, queue, and session will not work properly, disconnecting our users at every deployment.

To fix this we need Redis, it can be created the same way as our MySQL/PostgreSQL database.

Again, you will need to copy the credentials found in the Variables panel to your .env file, and configure Laravel session, cache, and queue to use the Redis driver.

4. Customizing the build step

During deployment, Nixpack will install your project dependencies and run the build command of your package.json to build assets:

composer require
[yarn|npm|pnpm] install
[yarn|npm|pnpm] run build

This is fine if you are serving a simple static site, but it is missing some Laravel specific steps.

The best way to do this is to set the NIXPACKS_BUILD_CMD environment variable to run the following commands:

[yarn|npm|pnpm] run build
php artisan optimize
php artisan migrate --force

Notice that we need to include the assets building step, as it will be otherwise replaced by our new commands.

I illustrate a simple approach here by running each command in a chain with &&, but you could put all this in a composer script, a bash script or a Makefile.

5. Creating a worker server

Railway only allows a single process by server, you currently have a web process running nginx and serving your PHP code.

What if you need another process to run a queue job in your app?

Then we just create a new server to serve that exact purpose!

In your Railway project, click on the new button, and choose your code repository again to create a second server.

Copy all your environment variable to make sure both code instances run with the same configuration, and override the NIXPACKS_START_CMD variable to run Laravel queue worker instead of a web server.

Your worker should now process your queue jobs. You can create as many workers as you want with different configuration to suit your project's needs.

6. Make signed route works

You might already experience issues with signed routes if you worked with a load balancer before.

When setting up a project, Railway will receive the request and proxy it to your server with the HTTP protocol.

Request -https-> Railway -http-> Server

When generating a signed route, Laravel with create a hash value of the full URL (which will be https), but when a user clicks the link, your code will verify the signature hash with a URL starting with http instead of https, making the signature invalid.

There are two things you can add to your code to prevent this, first force all URLs to be generated with the https protocol. This can be done in your AppServiceProvider boot method:

public function boot()
{
    if ($this->app->environment('production')) {
        URL::forceScheme('https');
    }
}

Then we need to trust Railway proxy to serve https, this can be configured in the TrustProxies middleware by setting the proxies property to a wildcard *:

<?php

namespace App\Http\Middleware;

use Illuminate\Http\Middleware\TrustProxies as Middleware;
use Illuminate\Http\Request;

class TrustProxies extends Middleware
{
    protected $proxies = '*';

    ...
}

Using a wildcard might not be a best practice, but I could not find a list of Railway IPs, let me know if you find one!

7. Blue green deployment

Finally, we need to make deployment zero-downtime. For this, we need to make sure that when a new deployment is creating a new server, Railway can verify our code run properly before switching user traffic to the new server and shutting down the previous one.

Railway offers health checks that do exactly this, you can choose the route that will be requested, and when it returns a success code (2xx), Railway will know that your server is ready to receive requests.

Conclusion

I've been looking for the "Vercel for PHP" for a long time, Railway is still a young service that lacks some flexibility, but the developer experience make up for it. I can't wait to see it evolve in the following years!

That said, I still use services like Laravel Vapor or Laravel forge, that are pricier but offer better performance, flexibility, configuration and remain my go-to platforms for serious professional project.

Why I learned the Linux command line as a developer, and you should too

Nicolas Beauvais — Tue, 26 Jul 2022 09:14:00 +0000

It’s always intimidating to find yourself in front of a command line when beginning your journey as a developer. We have the chance to live in a world where you can choose to do pretty much anything from a comfortable GUI, so why bother working with an old school terminal?

Read the original article on DivingLinux.com

Well, let me tell you that learning to use a command line is far from outdated, and it remains one of the most powerful tool to improve your productivity. I personally chose to focus on Linux, but developers working on macOS or Windows (with WSL2) can benefit just as much from it, and thanks to POSIX compliance, apply this knowledge on most operating systems.

I tell you this from experience

I'm a full-stack developer working with Linux for the past 7 years, and slowly embraced the command line, using it every day to execute simple and complex tasks.

The first time I was presented a terminal, all I saw was an inefficient and complicated way to do the things I already knew how to do with the native applications available on my operating system, so why bother?

Even if I did not like it, it was the only way I knew to tinker with servers, mostly to configure Apache to host my newbie PHP code online. From theses simple operations I got used to doing more things, started to develop confidence in my skills to a point where I can’t see myself working without a command line, not only to work with servers, but also on my desktop.

It’s hard to illustrate how learning to use a command-line might be a good idea, so we will explore together a few advantages of the command line with real-world uses-cases, and I encourage you to perform each of them on your computer for comparison.

Quickly try something, fail, and iterate

Small trial and error hacking is one of the thing that I love the most doing in a command line.

A recent example, I found a government website that list all general practitioner in my city, along with their status on accepting new patients. After a digging a little, I discovered that the list is available in JSON format, on a public URL.

Could I create an automated task that notify me when a general practitioner becomes available, all from a Linux command line? Of course, I can do that!

First I need to get the JSON file, this can be done with curl, make the JSON data readable for exploration, and finally filter it, both tasks can be done with jq :

student@waddle:~/$ curl https://health.gov/available-gp.json \
| jq '.[] | select(.available == true)'

{
"name": "Dr. John Doe",
"available": true
}

Surely, finding the right combination of commands takes experience and time, and you could do the same thing with a few lines of Python or JavaScript. But for simple tasks like this, I find the terminal more efficient, no needs to set up a development environment, create a project, install packages, or start a code editor, all I need is my terminal.

Once you know how to properly navigate your terminal, you can try to tinker with grep, sed, awk, combined with piping and redirection. This will open you to a whole new world of possibilities.

Automating common tasks

Now I would like to automate finding available doctors and receive some sort of notification when a new availability is discovered. For this, I need to check if my list has any results, and if that's the case, receive a desktop notification.

student@waddle:~/$ curl https://health.gov/available-gp.json \
| jq '.[] | select(.available == true).name' \
| xargs -I{} notify-send "Found available general practioner" "{}"

There's some dark magic involved for the beginners eye. The jq command will return every available general practitioner name, and thanks to the pipe to xargs, a notify-send command will be executed for each returned line, which means no notification if no results.

I can now execute this command every hour with a Cron task to fully automate the process, all it took is about 10 minutes.

Learning about Cron and systemd are great ways to start playing with automation. You can for instance build your own backup system with a single command using rsync in a cron task.

Master your developer tools

It doesn't matter if you're currently a frontend or backend developer, knowing to use a command-line will give you the most flexibility in terms of developer tools.

Both need continuous-integration and continuous delivery, that most probably run in a Linux server. Both need version control, package management, and testing tools that run in a command line.

You can use a GUI for 90% of your use cases, and it's completely fine. But when you run into an uncommon error or want to perform a very particular task, you will have to go back to your terminal, simply because most GUIs only replicate a subset of the raw capabilities of command-line tools.

A simple way to make yourself more comfortable using developer tools in the terminal is to replicate with a command line something you usually do in a GUI.

For instance, I like to see my branches and commit history in GitKraken, as it makes it more visual and understandable to manage a Git repository.

A quick Google search will show me that it's in fact possible to get a similar visual directly in a terminal with the following command:

student@waddle:~/$ git log \
--pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' \
--graph \
--abbrev-commit

* 1e274a9 - (origin/main, origin/HEAD) WIP server provisioning (1 day ago) <Nicolas>
|\
| * b62d50d - Base server driver abstraction (2 days ago) <Nicolas>
|/
* e1fdf32 - Initial commit (2 weeks ago) <Nicolas>

It's not convenient to type, or even remember, this command, which makes it the perfect candidate for creating a Git alias.

student@waddle:~/$ git config --global alias.pretty "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

Now all I have to do is type git pretty to get the expected result in a few milliseconds, and I can combine it with other tools like grep to quickly search a commit.

Learn to do things once, apply everywhere

As stated in the introduction, most of the base commands you will use in a terminal are POSIX compliant, which mean that you can use them on macOs, Windows with WSL2, Linux desktop and server.

By developing the habit to work in the command-line, you will also get used to work in a remote server environment, making the switch between desktop and server friction less. Learning to perform system administration and DevOps tasks when you are comfortable with a terminal and a few base commands is much easier.

Sure, the tasks performed on a server and on your desktop aren't the same, but the tools are common between the two, in most cases running sed on macOS, Ubuntu or Debian server will provide a fairly similar result.

Expand your stack

Being at ease working in a command line, especially on a Linux operating system, is the perfect gateway to expand your knowledge.

I personally started my career as a front end developer, learned backend along the way, and later system administration and DevOps to securely host and deploy my code on the cloud. This does not make me an expert on every topic, but knowing how each pillar works definitely make me a better developer.

Having at least a base knowledge of how a Linux server work will make you a better backend developer, and understanding a bit of networking / caching / DevOps will make you a better front end developer.

And as most action on a Linux server are made from a command line, it's the perfect starting point.

It's not all fun and games, at first

As a beginner, doing tasks from a command line will be painful and slow. Give yourself enough time and practice to create the neural pathways that will make you able to “think” in command line terms. After a few weeks of doing small tasks it will become as normal as breathing, you just need to force yourself a little to get there, and it will be worth it.

If you want to learn more on this topic, consider trying DivingLinux.

How to choose the best Linux distribution for your use case

Nicolas Beauvais — Mon, 27 Jun 2022 08:00:02 +0000

The Linux ecosystem is large, and a proof of this is the large number of Linux distributions you can choose from. However, this itself can be overwhelming for a user with no Linux knowledge. So today, I will help you answer the question, Which is the best Linux distribution for me?

Read the original article on DivingLinux.com

Many distributions but Linux being Linux

We already learned in our introduction to the world of Linux that Linux is in fact just the Kernel piece of an operating system. That kernel being Open Source allows it to be used by anybody to make a full operating system that are called Linux distributions.

Each one of them is different from the others, but share the Linux kernel technology. This makes that even if they are different in policy, behavior or interface, we are talking about very similar systems from the technical perspective.

So, you can select between many distributions to suit your needs. Do you want a robust and stable system, even sacrificing new features? Don't worry, there is always one that meets those requirements; or on the contrary, do you need a very active distribution with recent versions of applications? There is also one with those features.

In this way, it is very difficult not to find the ideal Linux distribution.

But not everything is so easy and simple, there are some considerations that are always good to know before making the choice. These considerations can influence the way in which the distribution is used or the purpose of its use.

Ease of installation and use

One of the first criteria for evaluating a distribution is its ease of installation and use.

Long gone are the days when installing and using Linux was for geniuses. Now, most Linux distributions are easy to install and use.

However, there are Linux distributions that place special emphasis on ease of use. These are oriented towards the novice Linux user or those who don't want to complicate things.

In this range we find Ubuntu, Linux Mint and Elementary OS. They are stable distributions that have an effortless to use installer and once installed, they have everything you need to get your hands on it without any problems.

Source code and licence of the distribution

One of the most exciting thing about Linux distribution is that the Linux Kernel use the GPL v2 license, which force all Linux distributions to publicly publish their source code.

Open source doesn't mean free, for instance Red Hat enterprise Linux a distribution focused on professional users, has a paid license. You can still access the source code, compile it by yourself and use it on your home PC. Of course restrictions apply, they own the trademark and copyrights on it, so you can't redistribute it. This model works because they provide enterprise level support and other service with a lot of value for big companies.

For personal usage, there's little chance that you require a commercial distributions.

Hardware is also important for choice

Computers and technology are advancing, but not everyone has the opportunity to change hardware frequently. That is why there are Linux distributions that focus on upgrading so that they can be used on older hardware.

As a general rule, these distributions don't have a polished and refined graphical interface as you might expect these days. However, they are very efficient and can revive old forgotten computers, or devices like Raspberry Pi.

Some of these distributions are: MX Linux, Sparky Linux, Lubuntu, and AntiX.

Active development guarantees support

Most distributions are free to use, and provide no guarantee of continuity in their development, leaving users who have put their trust in their projects abandoned. So, it is important to choose a distribution that has not only an active development but a consolidated and mature one.

In this sense, distributions supported by a serious and responsible company can be a viable solution. Among these, Ubuntu, Fedora, and openSUSE stand out.

Although there are also others that are based on a strong, consolidated and mature community. In this line we have the very important Debian Arch Linux or Linux Mint.

An active development guarantees that the distribution will not be suddenly abandoned, which will give you security when using it. In addition, you can be sure that new features will be added, bugs will be fixed and packages will be widely available.

Community support or commercial support?

In this segment, it depends on what you are looking for in the Linux distribution. There are some that have the possibility to purchase a license and with it technical support. Others do not.

Often the distributions with commercial support are reserved for companies that buy these licenses for their workstations. This is understandable since that for enterprise, stability is fundamental. It is also possible to choose distributions for production servers, which increases the importance of support.

On the other hand, Linux can be used domestically and in this case, it is best to use serious distributions with community support.

Stability or novelty?

In general, Linux distributions are stable and reliable. There are distributions that have stability as a premise and will only add new packages and version once every few year.

On the other hand, there are Rolling Release distributions that do not have a stable release cycle but are updated frequently. These distributions, although stable, are not as reliable as others, but here what is important is the novelty.

So in this aspect, the decision lies only in terms of necessity, if your computer or server break during a rolling release update you will need the skills and time to fix it.

Privacy and security taken to another level

There are also Linux distributions that put a special emphasis on security and data privacy.

For example, there are distributions specially designed to erase all our tracks and provide us with absolute anonymity. Important in countries where there is no freedom of expression or where there is any kind of danger. They are often used by criminals, whistleblower or activist to stay protected from government surveillance. One of the well-known distribution for privacy is Tails which is configured to only use the Tor network.

Most Linux distribution have good security default, but there are distributions specialized in defensive security. These distributions are great for enterprise user in sector that need high level of security on desktop or production servers. Qube OS or Fedora Silverblue are known for putting an emphasis on security.

Finally, some distribution are focused on offensive security, packaged with tools for penetration testing, ethical hacking and auditing. The most famous one being Kali Linux.

Software components

The Linux kernel is not enough to get a good operating system, thus many other pieces of software are required by default in a distribution. For instance, some experienced users hate working with SystemD, a popular system manager used by a lot of distribution, other will choose a distribution on the base display server communications protocols provided, X or Wayland.

For a beginner user these requirements should not be much of an issue, unless you need to work with a niche software that require specific pieces to be available in your distribution.

Which Linux distribution should I choose?

As you may have noticed, there are many Linux distributions to decide from. And the answer depends on your needs and wants. But I will introduce you to some Linux distributions that are recommended for beginners:

Ubuntu

When Ubuntu was born, it was born with the motto "Linux for human beings" so the main letter of introduction is that it is simple but modern, besides being stable and supported for several years.

Aesthetically, it is impeccable thanks to the GNOME desktop environment. It has an excellent documentation, and it is also the distributions with the biggest online community.

One point against it is that Canonical, which is the company behind Ubuntu, pushes the use of snap packages which are heavy and a bit slower. This push has led to Firefox being packaged in this format.

Pros:

Easy to use.
Stable, thanks to being based on Debian.
Good community support.
Possibility to purchase support.
Large number of packages.

Cons:

Not the most resource efficient.
Requires modern hardware.
Canonical's snap packages are heavy.

Linux Mint: From Freedom came elegance

Linux Mint is based on Ubuntu. So, it shares essential packages and components such as the kernel, graphics stack and so on. Therefore, what is the difference? Its desktop environment and mint-apps.

The desktop is not GNOME but a fork of it called Cinnamon, which has a more traditional look but built with modern technologies.

Mint-apps are applications created by the distribution's development team that give a simpler and more consistent feel to the distribution. These include a text editor, media player, update manager and so on.

Pros:

Very stable.
Secure updates through the graphical interface.
Better memory consumption.
Traditional but customizable interface.
Great community support due to being based on Ubuntu.

Cons:

Conservative to innovate desktop
Slow development cycle
Include many packages by default.

Debian

Debian is the base distribution used to build Ubuntu, Linux Mint, and many others. Thanks to a very conservative development cycle, Debian acquired the reputation of being one of the most stable distribution on the market. But this stability come with the cost of having packages that sometimes can be 1 or 2 years out of date.

Another aspect of Debian is that it is widely used both on servers and on the desktop. Moreover, although GNOME is the default desktop environment, you will be able to choose between a few others like Plasma or XFCE.

Debian is my personal distribution of choice when I need to set up a Linux server, and it's also the one used for the student servers of the Diving Linux command-line course.

Pros:

It is very stable
Excellent community support
Its package repositories are huge.
Great base to make it your own

Cons:

Somewhat outdated packages
Development branches not so clear to the user
A bit less friendly for newcomers

Arch Linux

Not all users can a complete and functional installation of Arch Linux. The reason, the installation is modular, and it is necessary to play with many configuration files. This makes it a distribution focused on those who already know Linux or who want to learn about it.

Arch Linux is a rolling release distribution that is constantly updated, bringing the most up-to-date packages. This is a great distribution to learn the many components of a Linux distribution, as you will have to work with many of them to get it to work as you want. By default, an Arch Linux installation is kind of raw, which makes it a good starting point to create something truly customized to your taste and needs.

Pros:

Latest updated packages
Large package repository
Good community and the best Wiki of all distributions

Cons:

Being a Rolling Release, Arch is not as stable as others
Difficult to install and use for the novice user
Strictly community support

Kali Linux

Kali Linux is a security distribution derived from Debian. So, it inherits from it the number of tools available and some of its support. It is a particular distribution because it is designed specifically for computer security, computer forensics and advanced penetration testing. I would not recommend it to beginner, unless you need it to learn and practice penetration testing, security research, computer forensics or reverse engineering.

Pros:

Comes with specialized professional tools.
Unique in its style.
Good support

Cons:

Installation different from the rest.
Don't use it if you're not aiming to be a security professional.

Fedora

Fedora is maintained by Red Hat, but it has the reputation of being innovative because it is where the first tests of packages or technologies are made. By default, Fedora come with the latest Gnome desktop and SELinux enabled, making it a stable, secure and beautiful distribution, well suited for professional use.

Fedora is emerging as a solid alternative to debian-based distributions. It also gave birth to other projects like Fedora Server, Fedora IOT and Fedora Silverblue. I've personally used Fedora on my laptop for the past year and been happy with it.

Pros:

Great combination of stability and package versions.
Abundant documentation and support.
Backed by Red Hat.

Cons:

Less packages than Debian-based distributions
SELinux being activated by default can complicate things for beginners

MX Linux

MX Linux is a lightweight Debian-based distribution that aims to provide users with an operating system that is well cared for in every way. Thanks to MX Linux, you will be able to dust off old computers and give them an updated system without sacrificing features.

One of the main features is speed. It's very agile and with a polished desktop. Of course, being focused on non-new computers, it is possible to miss some new features.

Pros:

Based on Debian Stable.
Active development.
Friendly community.
Low resource consumption.

Cons:

So thin that it may lack features.
Uses lightweight desktop environments and lacks certain commodities.

Lubuntu

Lubuntu is another lightweight distribution that incorporates a desktop environment called LXQT that combines the simplicity and power of QT. The result is a complete and aesthetically beautiful distribution.

Pros:

Based on Ubuntu
Large number of programs available
Good number of applications installed by default
Easy to install

Cons:

Doubts about its development
As in MX Linux, it is lightweight and may be insufficient.

Conclusion

There are many Linux distributions and there are many criteria to evaluate before making a final decision. Things like ease of use, support, and philosophy are all factors in the decision you will have to make.

So, Which Linux distribution should I choose? The answer depends on your needs but in general if you have modern hardware Ubuntu, Linux Mint and Fedora are all great choices. If stability is a primary factor then Debian might be the optimal Debian option.

In any case, you will have a robust system based on the great Linux kernel.

If you want to learn more on this topic, consider trying DivingLinux.

You will learn to use Linux from the command-line with confidence, by doing interactive hands-on exercises, and build strong foundation in monitoring, networking, and system administration.

Slack workspaces in the browser

Nicolas Beauvais — Tue, 04 Jan 2022 07:25:52 +0000

I always try to avoid using Electron apps when I can, more so when I need them running all day like Slack. It doesn't make much sense to me, it forces my computer to run another WebKit engine just for Slack when it already works perfectly in a browser.

But Slack does not offer a way to get all workspaces notifications in a single tab, and keeping 3-5 open tabs just for it is annoying, making the Electron app mandatory to use.

If you were stuck like me in this situation, I have exactly what you need: a way to activate Slack's workspace switcher in your web browser!

All you need to make this work is to change your favourite browser's user agent to make Slack think that you are using a chromebook, as detailed in this stack exchange thread.

You can use the great Tampermonkey extension, or similar, to easily change your user agent on the Slack website. If you do not know about this extension, it allows you to run a user-defined script on a particular website, and more things outside this article's scope.

Once installed, you need to create the following script that will change your user agent, and make the Slack website think that you are running the latest Google Chrome version on a Chrome OS laptop:

// ==UserScript==
// @name        Enable Slack workspaces in the browser
// @namespace   slack.com
// @version     https://dev.to/nicolasbeauvais
// @description Enable Slack workspaces in the browser
// @match       https://app.slack.com/*
// @match       https://app.slack.com/
// @grant       none
// @run-at      document-start
// ==/UserScript==

(function () {
    'use strict';
    Object.defineProperty(navigator, 'userAgent', {
        value: 'Mozilla/5.0 (X11; CrOS x86_64 10066.0.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36'
    });
})();

If you never used Tampermonkey before, you can find many online tutorials that will show you how to add a script.

Be careful with the scripts that you add to Tampermonkey, you should never add code that you do not fully understand.

And that's it, you can now open all your Slack workspaces in a single tab, and receive all notifications, just like with the Electron app.

A practical beginner introduction to discover the world of Linux

Nicolas Beauvais — Mon, 13 Dec 2021 16:55:12 +0000

Linux, you already heard of it, maybe even used it once or twice for work, and certainly a thousand of times without knowing. It has a different aura, something special that you do not feel when thinking about Apple's macOS or Microsoft's Windows, it's loved by geeks, power user, misfits, scientists, engineers...

Read the original article on DivingLinux.com

It's not advertised on TV or online, you most likely won't see any computer sold with Linux in a shop, and yet Linux and its derivatives runs:

100% of the top 500 supercomputers
96% of the internet
85% of all smartphones
The International space station
Nasa's Perseverance rover on Mars

When it comes to desktop use, Linux sits at 2% [6] of market share, 5% if we count ChromeOS which is based on Linux, way behind macOS and Windows. Going through all the reason behind this would make this article too long and boring [7] so we will stick to one key point: Linux is hard for newcomers.

You need to learn a new vocabulary, find new online resources, learn new ways of doing things, even if the reward is worth it at the end, this can discourage the most tech-savvy users. To make it easier for you, I've made a compilation of the questions I get the most from my students when they begin to learn Linux, and answered them with brief overview answers to make it easy to digest.

Questions covered in this article:

What exactly is Linux?
What is the difference between Linux, macOS and Windows?
Are UNIX, and Linux the same thing?
What is GNU?
Is macOS based on Linux?
What is a Linux distribution?
How can I try Linux as a beginner?
Tl;dr

What exactly is Linux?

You probably know that Linux is an operating system, but almost nobody uses it directly as is. When we refer to Linux, we most often refer to any operating system that is based on the Linux Kernel.

The Linux Kernel is a secure and stable base program that will handle all the things that you typically don't think about when using a computer, like communicating with the processor, handling the memory, connecting to the internet, receive the keys you pressed on your keyboard and display them on your screen.

This base kernel is then completed by other program to make it operable (see GNU), do specific tasks, or make it easy to use by non-technical users, like Android on mobile or Ubuntu on desktop.

What is the difference between Linux, macOS and Windows?

Contrary to macOS and Windows, the Linux Kernel is free and open-source, meaning that anybody can see the code [8], improve it for everyone or modify it for their particular use case. It also means that you can install and use it for free on any device, but if something goes wrong, there is no hotline to complains to, you're on your own.

As it is not locked in any way by a vendor, you can do anything you want with a Linux operating system. Customize its appearance or behavior, and also make it completely unusable with an ease that you won't find on Microsoft an Apple operating systems. Which is why Linux is loved by power users, and Windows / macOS by companies that want to keep a maximum control on their fleet of devices.

Linux and macOS are both based on a UNIX-like architecture, so there is a lot of similarity between the two operating systems, and most of the command-line knowledge that you learn from one can be applied to the other. Windows on the other end use its own architecture, although, since Windows 10, the Windows Subsystem for Linux (WSL) makes it possible to use a virtualized Linux Kernel and run Linux binaries directly in Windows.

Are UNIX, and Linux the same thing?

They're not, UNIX was created about 20 years before Linux. UNIX got popular with businesses and academics in the 70s, but the creators of Unix used a licensing scheme forbidding modification of the operating system. At this time the GNU project started with the goal of creating a UNIX compatible operating system that was open source and free to use.

Unfortunately the GNU kernel was not complete and progress was slow, then Linux got released and became the go-to Kernel for the GNU suite creating the "GNU/Linux" operating system that we know today.

The UNIX system gave birth to a lot of other operating systems, called UNIX-like[9], as they do not share the same code, but are most of the time compatible and follow a similar architecture. Linux, macOS, FreeBSD or OpenBSD are just a few of them.

What is GNU?

If you look anything related to Linux online, you will see theses three letters in no time "GNU", and sometime in the form "GNU/Linux" but what is it?

GNU is a collection of software written by the GNU project, the most famous being Bash, Gimp, and GRUB to only name a few. Started about 10 years before Linux, had a crucial role in the history of open source and free software, and remains highly important to this day, it is also at the origin of the General Public License (GPL)[10].

The GNU software collection offer a base operating system when coupled with a Kernel (Linux). This is why you can come across the name "GNU/Linux" because most operating-system that use Linux as a Kernel will also use some part of the GNU software collection. There's been some conflict on this particular naming so let's not expand on that, but I advise that you do your own research on the subject[11].

GNU coreutils

A big part of the GNU software collection, that is less known by its name, is coreutils. It is a set of tools to help you use your operating system, most base commands on a Linux operating system, like cd, ls, cp, cat, echo and a few dozens more are part of GNU coreutils.

Is macOS based on Linux?

As we've seen previously, macOS uses a UNIX-like architecture, with its own kernel called XNU[12]. So macOS is definitely not based on the Linux kernel, but they do share a lot of architectural concept and standards. Both operating systems are POSIX[11] compliant, making it easy for user to move from one to the other, with shared base commands that are implemented in a similar way.

What is a Linux distribution?

Installing the raw Linux kernel on your computer is like driving a car, with nothing else than the engine. To do task on your computer you need many tools, something to handle Wifi, bluetooth, a file explorer, a web browser, and so on.

Just like Windows and macOS come prepackaged with everything you need for a general use, Linux distributions, commonly called "Distro" are fully operational operating systems. Each distro as its particularity and targeted audience.

Here is a brief overview of well-known Linux distribution:

General purpose

Ubuntu
Debian
Fedora
Manjaro

Advanced use

Arch linux
Gentoo
Void Linux

Cyber security and penetration testing

Kali linux
BackBox
Parrot OS

You can find information on the wide range of Linux distributions on the distrowatch.com website.

How can I try Linux as a beginner?

There is already a fair amount of online tutorials with step-by-step instructions for each technique explained. So I will just give you an overview of what you could do to test a Linux Distribution at home.

Virtual machine

The easiest way to try a Linux distribution is by using a Virtual Machine, for this you can install VirtualBox on Windows or macOS. Choose the Linux distribution that you would like to try and download it as an ISO file, you should find this option on most well-known Linux distribution website. Now run that ISO file using VirtualBox and Tada!

Virtual machine is a way to recreate a "fake" computer on top of your running computer, which can be slow if you do not have a modern computer, but it is the easiest and safest way to learn and try new Linux Distributions.

Live USB

A live USB is a way to install an operating system, in our case a Linux Distribution, on a USB sticks. This allows to boot your computer using the operating system installed on live USB stick instead of the storage device where your computer's usual operating system is installed.

All you need for this method is a USB stick, the ISO file of the Linux distribution that you would like to try, and a tool to move the ISO file to the USB stick and make it bootable. You can try BalenaEtcher which work on Windows and macOs.

Dual boot

The dual boot technique is probably the most complicated one, and you can damage your computer if you're not careful. Dual boot consist on installing a full Linux distribution on your computer along your main operating system (Windows or macOS). This method is probably the best if you are serious about learning to use a Linux operating system, you will be able to leverage the full hardware power of your computer, and still be able to go back to Windows or macOS when necessary.

Creating a dual boot computer can be challenging for beginners, make sure to back up all important files, and do not hesitate to get some help if you do not fully understand a step of the process.

Other computer

One last way is to install Linux on a computer that you are not using, you could also buy a cheap second-hand laptop to experiment. This way you do not risk damaging your main computer.

Tl;dr

Linux is a kernel, a piece of code that allow other software to communicate with the hardware of your computer, it is inspired by and compliant with the UNIX kernel.
Combine the Linux kernel with GNU utils, a set of basic programs, and you have a basic, but fully working operating system which is referred as "GNU/Linux".

MacOS is based on UNIX too, which is why there is similarity between macOs and Linux-based operating systems.
Distro, or distributions, are variant of the "GNU/Linux" operating system, with carefully chosen default settings and installed programs that make it easier to use.

Conclusion

I hope this article cleared things out for you. I did not include many names or dates to not complicate things too much and keep the explanations as concise as possible. Don't hesitate to look for more info on Wikipedia or other sources I linked, the history of Linux and the people who created its ecosystem is fascinating.

Sources:

If you want to learn more on this topic, consider trying DivingLinux.

You will learn to use Linux from the command-line with confidence, by doing interactive hands-on exercises, and build strong foundation in monitoring, networking, and system administration.

Silently validating a Laravel request

Nicolas Beauvais — Mon, 29 Nov 2021 18:26:33 +0000

While working on the Content Security Policy implementation of Phare, I had to implement a public endpoint to receive violation report from web browsers. The issue being that this endpoint URL can receive data from anyone that throw a request to it, and in slightly different format depending on the browser.

As the input cannot be trusted, using some form of validation is mandatory, Laravel validator is perfect for this, and as it can be quite a complicated validation, using a Form Request seemed to be the most appropriate.

This is where things can get annoying, if a browser with an old content security policy sends a payload that I do not which to support in my API, the Form Request will send a response with a 422 status code, which will create a console error in the browser. And if a malicious script kiddy troll want to send a payload to the endpoint, I do not want to the API response to contains exactly how to correct a wrong payload.

After some digging, I found out that the FormRequest class has a failedValidation method that throw a ValidationException, caught by the Laravel exception handler to create the default 422 response with the error bag.

// source: vendor/laravel/framework/src/Illuminate/Foundation/Http/FormRequest.php

class FormRequest extends Request implements ValidatesWhenResolved
{
    ...

    /**
     * Handle a failed validation attempt.
     *
     * @param  \Illuminate\Contracts\Validation\Validator  $validator
     * @return void
     *
     * @throws \Illuminate\Validation\ValidationException
     */
    protected function failedValidation(Validator $validator)
    {
        throw (new ValidationException($validator))
                    ->errorBag($this->errorBag)
                    ->redirectTo($this->getRedirectUrl());
    }

    ...
}

By overriding this method in our own FormRequest, we can throw a custom ValidationException that fail silently, by returning a 2XX status code and not showing any error message.

Let's start by creating our custom exception, I named it SilentValidationException, it takes two parameters, first an instance of the Laravel validator which will contain the errors of the FormRequest validation, and a custom exception message. I chose to store the error payload as an array to reuse it later.

<?php

namespace App\Exceptions;

use Exception;
use Illuminate\Contracts\Validation\Validator;

class SilentValidationException extends Exception
{
    private array $errors;

    public function __construct(string $message, Validator $validator)
    {
        parent::__construct($message);

        $this->errors = $validator->errors()->toArray();
    }

    public function getErrors(): array
    {
        return $this->errors;
    }
}

We can then make our FormRequest that will throw the SilentValidationException if the payload validation fail.

<?php

namespace App\Http\Requests;

use App\Exceptions\SilentValidationException;
use Illuminate\Contracts\Validation\Validator;
use Illuminate\Foundation\Http\FormRequest;

class ContentSecurityPolicyViolationRequest extends FormRequest
{
    public function authorize(): bool
    {      
        return true;
    }

    public function rules(): array
    {
        return [
            'csp_report' => [
                'required',
                'array'
            ],
            // Many validation rules
        ];
    }

    protected function failedValidation(Validator $validator)
    {
        throw new SilentValidationException(
            $validator, 
            'Content security policy violation ignored'
        );
    }
}

Now, if you try that code, Laravel will handle our SilentValidationException as any other exception and show an error page. To avoid this, we need to change the exception handling behaviour for this particular exception. This can be done in the app/Exceptions/Handler.php file.

There are two things to do in that file, we first want to register our custom exception in the $dontReport array to avoid logging the error in your log file, Sentry, Flare or whatever error service that you use.

<?php

namespace App\Exceptions;

use Illuminate\Foundation\Exceptions\Handler as ExceptionHandler;
use Illuminate\Support\Facades\Log;

class Handler extends ExceptionHandler
{
    /**
     * A list of the exception types that are not reported.
     *
     * @var string[]
     */
    protected $dontReport = [
        SilentValidationException::class,
    ];
}

Now this does not change the response, to do this we need to register a callback in the register method of the Handler class, as explained in the documentation.

Here we can get creative and do whatever we want with the error payload before sending the response. I could for instance store the errors in a database table to see which error occurs the most to make my API compatible with more browsers.

To keep this example simple, let's just log the validation errors and return a no content response:

<?php

namespace App\Exceptions;

use Illuminate\Foundation\Exceptions\Handler as ExceptionHandler;
use Illuminate\Support\Facades\Log;

class Handler extends ExceptionHandler
{
    ...

    /**
     * Register the exception handling callbacks for the application.
     *
     * @return void
     */
    public function register()
    {
        $this->renderable(function (SilentValidationException $exception) {
            Log::info($exception->getMessage(), $exception->getErrors());

            return response()->noContent();
        });
    }
}

That's it! You now know how to silently validate a payload using a Laravel Form Request.