DEV Community: Andrés Villarreal

Conquering Entropy: Reducing Risk

Andrés Villarreal — Sat, 19 Sep 2026 08:50:52 +0000

Part of “Conquering Entropy”

First, I have to admit some of my recommendations on this topic are based on my own experience and anecdata, and not so much backed by numbers, please take them with a grain of salt.

Risk Management

Shipping code is risky. Any change could break the system. Over the years, I have learned to get comfortable with managing risk. For each change that I ship, I do a little risk assessment beforehand. It takes deep understanding of the system, as well as some intuition (which I fear pure vibe coders cannot reach). This is why I find it imperative to still have a clear mental model of the system I work with, even if most of the code is AI-generated. If I don’t understand the system, I cannot make an accurate risk assessment.

Accurate risk assessments are useful because they can guide you to allocate just the right amount of resources for a change (mental capacity, review effort, follow-up tasks). If a change is low-risk enough, I usually just do it and ship it, no follow-up needed. If it’s high-risk, I find a way to reduce the risk. Below are some strategies you can use for that.

Scope Changes Appropriately

The way big changes are built and delivered is tied to the development process of each team. Often, it’s recommended to split the tasks into smaller, deliverable chunks. This approach goes well when async work is preferred, but might make it harder to have a coherent high level understanding of the system. A proper review requires the reviewer to understand the work being done, the exact purpose of the change, and what impact it could have on the existing system. All of this must be obvious or clearly stated in the pull request (PR) description.

I’m not entirely convinced there’s a change too big to be broken down into smaller, individually deliverable and reviewable chunks. However, I understand why it would be preferable to quickly get a big chunk of code into the codebase rather than splitting it and risking merge conflicts, especially if the codebase sees a lot of traffic (common in monorepos).

Pair Programming Reborn

For big, risky changes I recommend pair or mob programming. Two or more people sit down, discuss and plan the change, scope it out, and implement it (feel free to include your coding agents here). Taking your sweet time during the planning phase can save a lot of time later on. It’s worth it.

A popular way to do this is to use Matt Pocock’s grill-me skill. I highly recommend it. The process encourages a shared understanding of the implementation. The team can then skip the review phase because they developed the solution together and are familiar with the code. Of course, some trust is also required here.

The biggest downside of this method is that it requires multiple engineers’ uninterrupted time, which might be tricky in some situations. But the benefit often outweighs the cost. The requirements are clear. There will be fewer bugs shipped and less rework, because of all the time spent planning and scoping. In my opinion, this is the most efficient way to get big, urgent changes in.

Because this method favors front-loading all the planning and scoping before writing code, it can be considered the opposite of the “ship small changes fast” approach. Therefore, it’s essential that the team deliberately picks which approach they will use for each task.

Another benefit of pair programming is psychological. It’s good for team building (I swear I’m not a manager!). I feel that with the use of coding agents and related tools, we engineers have become a bit more isolated. There’s a stronger focus on delivering a lot of tasks. Most touchpoints with teammates are about getting a review approved, or pushing back against their agent’s generated artifacts (tickets / code / documentation).

Observability is Essential

In my first programming job, we only knew if the system had a defect because an end-user reported a bug. When I think about how far we have come, it really feels like that was the stone age. You need to know what’s going on in your system! Ensure there’s some sort of observability set up: Logs, metrics, traces, user telemetry, etc. Use whatever vendor you want, ideally something that’s already in place. LLMs are great at consuming raw observability data and helping you debug issues, so take advantage of them!

Choose the Right Deployment Strategy

Reducing risk is another approach which works well for both big and small changes. There are several approaches to reduce risk when releasing changes. For me, it’s important to use the tools you have available already in your system. You don’t have to start all fancy with Kubernetes blue/green, canary, or shadow deployments (although these can be very useful for specific situations).

Make sure your system supports a way to quickly roll back a specific change, or to turn off a feature at runtime (for example by using feature flags). If paired with proper observability, this is often good enough for most use cases.

There are some techniques currently forming around a related concept: using agents to automate releases and observability, then “babysitting” the rollouts and determining whether the system is degraded. If so, the change is automatically rolled back and a human is involved. I think this has great potential, particularly for full-on “software factory” systems. When I find the opportunity to apply this technique, I will do a follow-up post with my findings.

Conquering Entropy: Cultivating Trust

Andrés Villarreal — Sun, 07 Jun 2026 07:53:43 +0000

Part of “Conquering Entropy”

Most of the issues I have with AI-generated code are related to trust. Do I trust the person who wrote this ticket? Do I trust that the engineer who opened this PR understood the ticket and guided the coding agent to implement it properly? Do I trust the coding agent’s implementation? Do I trust our test suite to catch regressions before they hit production? Do I trust our CI/CD to properly build, test, and deploy our change? Do I trust our observability setup to alert us when the ai-generated code breaks production? Do I trust the AI SRE (Site Reliability Engineer) to properly diagnose the issue and help us mitigate it? Do I trust GitHub not to have an incident when we need it the most?

Trust is hard to earn and easy to lose. So I think it’s crucial to foster a culture of trust within the engineering team. You must trust engineers to do the right thing.

Encouraging Accountability

I find it helpful to clearly communicate something like this: “You are accountable for what you ship. If this breaks production and you authored the PR, you should be there to fix it.”

If engineers are made accountable for the code they ship, they should be given the agency to produce it with their preferred methods. Even if you’re not AI-pilled, you have to admit that AI agents do generate a lot of code very fast. Code still needs to be generated, and the expectation is that now it’s cheap to generate a lot of it. To cope with this, engineers must be allowed to put some measures in place to ensure the quality of the codebase does not degrade.

In a healthy organization, the engineers should trust each other to only push code of reasonable quality. I say reasonable because it’s not pragmatic to obsess over quality and try to ship always 100% perfect code. Even before coding agents most code was already a buggy mess! So it’s understandable when a “good enough” solution is delivered. Often, we trade speed of delivery for quality, and incur some technical debt.

Here are some practices I have found useful to facilitate engineering accountability in this new era of coding:

Coding Guidelines

Have a clear technology strategy: take some time to decide what matters for your codebase and invest in clear guidelines. Both for humans and for the coding agents. Even if the humans don’t read the guidelines, their coding agents will, and will follow them (mostly).

Deterministic Tooling

Make heavy use of deterministic tooling to ensure code quality. Typed languages, linters, dead code detection, security scans, CI/CD, and so on. All of these tools existed before coding agents and help us in the fight against slop. (Stay tuned for a follow-up post with specific recommendations!)

Enforce Small PRs

Empower the engineers to reject unreviewable PRs. If possible, codify this criteria so any unreviewable PRs are immediately rejected. Of course, make sure to leave room for exceptions.

Own the Tests

Write test cases by hand. This is similar to the job of a business analyst. Deeply think about the feature and define proper test scenarios. Discuss this within the team. Coding agents can implement the tests, but they should be defined by humans.

Taste in Product

Work in tandem with product to have a coherent product vision. It’s very easy to go crazy with AI and implement whatever feature comes to mind. Make sure you only implement useful features that actually bring value to users!

Prototype

Throwaway code. Since code is very easy to generate now, it’s a good opportunity to try different approaches. Don’t just let the coding agent generate one solution. For example, try three radically different approaches and pick the one that best fits the problem and existing system.

Focus on the Outcome

Be pragmatic about the result. Sometimes the code is not the result. The result is a report, or a tool that helps you accomplish something else. For cases like this the quality of the code is not that relevant as long as the result is useful.

Conquering Entropy

Andrés Villarreal — Sat, 06 Jun 2026 07:44:19 +0000

A collection of ideas on how to manage entropy in codebases inundated with AI-generated code and survive in the process.

What’s Been Changing

Ever since coding agents became popular, my company’s monorepo line count has exploded. The number of pull requests (PR) has roughly doubled (conservatively), and so has the review burden on all engineers. People think the biggest problem now is that there’s too much code to review. But there’s way worse stuff!

Other negative consequences I have noticed:

Degraded shared understanding of the system, since most code is not written by hand anymore. We are missing this step, which helped us solidify our comprehension of the system and strengthen our mental models.
Artifacts which are difficult to understand. For example, tickets heavily written by AI, system design documents, code comments and documentation. This is due to the way LLMs write. People are calling this new language “Claudish” and I hate it because it muddles communication.
Jumping to conclusions too fast. As difficult as the LLM output can be to understand, sometimes it can be very convincing and people let their guard down and easily trust it. I think we need to “trust but verify” even harder nowadays.

I see a lot of anxiety and worry over what the profession is becoming. This one’s tricky and I’m afraid I don’t have any useful actions to help with this. Personally I have chosen to take advantage of the current tools and focus on maintaining a system that I can be proud of. But in a few years we might not even need humans for this.

More now than ever, it’s essential to be able to trust each other and the code we deliver.

AI Contributions Are Staying

In some open source projects (like Zig, NetBSD, GIMP or QEMU), AI contributions have been banned. Reasons vary, but I see a common thread: lack of trust. Slop, spam, untrusted code, no accountability, licensing.

Within a company, it’s not often feasible to ban AI contributions, as the business also expects that the engineers deliver at an accelerated pace. And the incentive within a company is usually to deliver more, show higher performance, get your promotion, salary increase, etc. So as long as there’s a tool that improves productivity (or looks like it does), people will use it.

I used to think that if AI usage kept incurring higher and higher costs, it would collapse and everyone would go back to writing code by hand. But I don’t think this will happen anymore. There’s many “good enough” open models that can be self-hosted right now, and they’re only going to get better. Some companies are already experimenting with this to reduce their dependency on the big AI providers.

So it looks like AI usage will not stop. I like it (societal and economical consequences aside). It’s allowed me to have a greater impact that I could have had before by doing a lot of the grunt work that is necessary but I never had the time for. Also allowed me to get so much more done on my side projects in which code quality is not the focus. It’s also fun to tinker with. I have tried many different setups and enjoy discussing these with my colleagues.

LocalStack License Changed, CI First to Know

Andrés Villarreal — Sat, 28 Mar 2026 15:09:45 +0000

LocalStack is a great product. It’s basically an emulator for the AWS cloud that you can run locally. We rely on it for development and automated testing. However, nothing comes for free. Understandably, the company behind this amazing piece of software has some bills to pay. They changed the license to require a subscription to run their provided Docker images. If the license is not provided as an environment variable, the image simply fails to start. Normally, this would not be a problem if we pinned our versions properly. But surprise, we don’t!

CI started “randomly” failing in the middle of the day and annoying all the engineers. I consider myself the self-appointed CI shepherd, so it was my responsibility to find out what was going on. Initially I thought this was just a couple of flaky tests, but after it started failing constantly, it became obvious we had a real problem. We use testcontainers with the S3 LocalStack image, and all tests which used this setup were consistently failing.

The nice thing is that I was able to reproduce the problem locally, so then I just bumped the log levels to the max and looked for funny stuff. After some log spelunking, I noticed the failing image was localstack/localstack:s3-latest. From there it was easy to find out LocalStack’s latest blog post explaining their licensing changes.

The immediate fix was to pin the image to version 4.4.0. For example: change localstack/localstack:s3-latest to localstack/localstack:4.4.0.

I would say the main takeaway from all of this is to pin your versions. Then you always know what you get. Package manager dependencies, docker images, Github actions, anything! Always specify a deterministic version. Never use latest or similar. Oh, how I wish reproducible builds were more widespread in the software industry!

Back to the LocalStack topic, now I am actively on the lookout for a proper replacement. I only need a local S3-compatible emulator. I have tried MinIO but for some reason it doesn’t seem to be a drop-in replacement and also has some funny business going on with the licensing. floci also seems promising although it’s quite new. Please reach out if you have any recommendations!

Our CI Doesn't Do Weekends

Andrés Villarreal — Sat, 24 Jan 2026 09:34:06 +0000

I think a codebase can tell you a lot about the people that work on it. From this specific example in particular, I felt very reassured that the team takes work-life balance seriously and never works on weekends.

For context, the software interfaces with old-school banking systems that famously do not run certain processes on holidays or weekends.

We had some logic to to an early return to avoid running a process on bank holidays, imagine something like the following:

if (isBankHoliday(new Date())) {
  logger.info("Skipping process on bank holiday");
  return;
}
// ... continue business logic below

This logic was not covered by any tests! Not to say that there were no tests, but they were more focused on what would happen on work days and not the fact that the code should not run on bank holidays.

This worked quite well, until somebody pushed changes on a weekend.

Weekends are considered bank holidays, so the check to avoid running on bank holidays was triggered and the tests failed. Fortunately, the changes being pushed on the weekend were not urgent and nobody was blocked by this.

The lesson we learned from this is that you should not work on weekends!

Although in all seriousness, the tests should have faked the date from the start to avoid this. Even if people are not working on weekends, it could be that they work in a different timezone, or the team needs to push an urgent hotfix during the weekend.

The way to do this using vitest is very simple:

// Pick a date that is definitely not a bank holiday!
vi.useFakeTimers({
  now: new Date("2025-03-03"),
  toFake: ["Date"]
});

By the way, vitest is very fast and very easy to migrate to from jest! Make the switch if you haven’t already!

fzf + SSH Config Hosts

Andrés Villarreal — Thu, 10 Oct 2024 18:42:48 +0000

SSH has a nice feature in which you can store aliases for frequently accessed hosts.

Combining this with fzf, you can have a nice quick shortcut to quickly pick a server to connect to into.

This comes in very handy if you need to ssh into different servers and forget their IP or hostname often.

Here’s a sample ssh config file (normally located at ~/.ssh/config):

# see https://man.openbsd.org/ssh_config.5 for all the available configuration settings
Host runner-staging
    HostName 10.0.0.8
    User alpha

Host runner-production
    HostName 10.0.0.9
    User beta

Host mainframe
    HostName mainframe.computer.world
    User hackerman

Here’s a small shell function which calls fzf with the hostnames configured and allows you to pick one to connect to:

s () {
  local server
  server=$(grep -E '^Host ' ~/.ssh/config | awk '{print $2}' | fzf)
  if [[ -n $server ]]; then
    ssh $server
  fi
}

Add this function to your .bashrc (or .zshrc, or whichever config file for your shell) and reload the configuration.

Now, you can quickly ssh into mainframe by typing s:

$ s

# fzf will allow to quickly search and pick your server
> runner-staging
  runner-production
  mainframe
  3/3 ──────────

# press enter and you will be connected!
[hackerman@mainframe.computer.world ~]$

Using AsyncLocalStorage for Better Traceability in NodeJS Applications

Andrés Villarreal — Sun, 29 Sep 2024 08:45:54 +0000

NodeJS has a neat API called AsyncLocalStorage. It’s used to share information across callbacks and promise chains.

For example, it is useful to share information for all the code executed when serving a web request. I also found it very useful to keep trace information to easily keep track of which item was being processed during a batch process.

The only caveat in my opinion, is that you need to wrap your code in yet another callback.

How to use `AsyncLocalStorage`:

First, create an instance of AsyncLocalStorage:
Then, use the run method to wrap your code:
Finally, use the getStore method to retrieve the shared state:

Real-world example

The previous example is very simple because it only shows how to use it.

Here’s a more elaborate example that will hopefully show why this feature is so useful:

import { AsyncLocalStorage } = from "node:async_hooks";

async function process() {
  try {
    await Promise.all([foo(), bar()]);
  } catch (err) {
    handleError(err);
  }
}

async function foo() {
  const { index } = asyncLocalStorage.getStore();
  console.log(`processing foo ${index}`);
}

async function bar() {
  const { index } = asyncLocalStorage.getStore();
  console.log(`processing bar ${index}`);

  if (Math.random() < 0.1) {
    // simulate a random failure
    throw new Error("A random failure happened");
  }
}

async function handleError(err) {
  const { index } = asyncLocalStorage.getStore();
  console.log(`Handling error when processing ${index}: ${err}`);
}

const asyncLocalStorage = new AsyncLocalStorage();

// process 20 things, asynchronously
const tasks = [];
for (let i = 0; i < 20; i++) {
  tasks.push(
    asyncLocalStorage.run({ index: i }, process)
  );
}

If you execute this code, it will clearly log for which items the failures occured, because the required information is available in the shared state exposed by AsyncLocalStorage.

Example of the output:

processing foo 0
processing bar 0
processing foo 1
processing bar 1
...
Handling error when processing 3: Error: A random failure happened
Handling error when processing 8: Error: A random failure happened
Handling error when processing 14: Error: A random failure happened

Starfield visualization in JavaScript

Andrés Villarreal — Sat, 31 Aug 2024 18:18:07 +0000

This is a simple, straightforward implementation of a visualization reminiscent of the classic Windows 95 starfield screensaver.

It is also interactive: you can touch the screen or use the accelerometer to influence the direction of the movement.

This is how it works:

Create a bunch of particles (100), each in a random position.
Every frame, move each particle further away from the center*. The further the particle is from the center, the more visible it will become. This gives the illusion that the particles are moving closer to the viewer, or that the viewer is going further into space.
The center is not really the center of the screen, but a variable point which can be influenced by the user by moving their cursor or tilting their device.
When the particles go outside of the view, put them near the center again, this keeps the visualization going on in perpetuity.

In this blog post, I want to share the heavily-commented source code to demonstrate how simple it is to create visually appealing animations with a few lines of code and basic math knowledge.

Please click here to see the visualization in action!

The code is available in this Gist:

Migrating From DokuWiki to Obsidian

Andrés Villarreal — Sun, 18 Aug 2024 19:37:56 +0000

About a year ago, I decided to move all my personal notes from DokuWiki to Obsidian.

DokuWiki is great software and has served me well, but I never utilized it to its full capacity. It’s biggest strength is that it’s a… wiki, and I was the sole user.

It made little sense for me to keep a service running when I could just have some Markdown files locally. And Obsidian provides a really nice UI on top of those Markdown files.

One reason I chose DokuWiki in the first place, is that it doesn’t need a database. All the content is kept in plaintext files. So if I ever wanted to move my notes elsewhere, it would hopefully be a painless process. In the end, I think it was a good choice, because the migration was quite simple.

The Migration Process

These are the steps I followed:

1. Copying the data folder locally

First, I needed to get the source text and image files from DokuWiki to my local machine. All of it is located at /var/www/dokuwiki/data/ for a common installation. This directory contains all the text files and images that comprise the wiki pages. This directory is configurable, so check your configuration if you’re unsure.

2. Convert all text files from DokuWiki Syntax to proper Markdown

The next step was to locate all the .txt files in data/pages. These files needed to be renamed to .md, and the content converted to proper Markdown.

DokuWiki uses its own syntax, which is not really used anywhere else.

I ended up writing a quick script to handle this, with some help from ChatGPT to speed up the process.

Main points the script covers:

Changing DokuWiki’s heading syntax to Markdown format.
Adjusting link and image paths to work with Obsidian.
Handling any quirks like list formatting.

3. Moving Media Files

After the text files were converted, I moved all the media files from data/media to data/pages. Obsidian can handle images and other media in the same directory as the Markdown files, which DokuWiki did not.

4. Final Touches

The last step was to verify everything in Obsidian. I went through my notes to check formatting and that there were no broken links or images. A few minor tweaks were necessary, but the script got me 95% of the way there!

Conclusion

It’s been about a year since I did the migration, and using Obsidian is much smoother. I just need to make sure the directory with my notes is properly backed up / synchronized between my devices. Obsidian offers this as a paid feature, but I didn’t want to depend on yet another 3rd party service. I simply use a Git repository to keep my notes.

For anyone looking to do the same or similar, I hope this post helps you out.

Here is a small peek of my notes in Obsidian’s beautiful graph view:

How to use Let's Encrypt certificates with Keycloak

Andrés Villarreal — Wed, 04 Jan 2023 16:28:41 +0000

Keycloak provides user federation, strong authentication, user management, fine-grained authorization, and more.

Here is a guide to enable HTTPS access to your Keycloak server using a free Let's Encrypt SSL certificate. The beauty of Let's Encrypt is its ease of use and the fact that it's free!

This guide assumes you have already installed Keycloak at /opt/keycloak/ using the official guide for bare metal installs, and now you want to enable HTTPS access. You need to have version 20 or higher.

In all the instructions below, be sure to replace <DOMAIN> with the actual domain you will be using. All commands in this guide must be run as root.

1. Install certbot

First you will need to install certbot. This depends on the Linux distro you are using.

For example, for apt-based distros such as Debian or Ubuntu, you can just run the following:

apt install certbot

2. Create HTTPS certificates

Set up certificates:

$ certbot certonly --standalone --preferred-challenges http -d <DOMAIN>

3. Configure Keycloak to use Let's Encrypt certificates

Change configuration:

vi /opt/keycloak/conf/keycloak.conf

Add or update the following lines in that file:

https-certificate-file=/etc/letsencrypt/live/<DOMAIN>/cert.pem
https-certificate-key-file=/etc/letsencrypt/live/<DOMAIN>/privkey.pem
hostname=<DOMAIN>

https-port=443
http-port=80

Update keycloak config:

$ /opt/keycloak/bin/kc.sh build

You're done! Now you can run the following command and Keycloak should now be accessible from the browser via HTTPS:

$ /opt/keycloak/bin/kc.sh start

4. Optional: Set up Keycloak as a systemd service

The official guide purposely leaves this open-ended because there are many ways in which you might want to handle the lifecycle of the Keycloak server. However, I think a good approach is to just use systemd.

4.1. Set up systemd service

Create user and group:

$ useradd -g keycloak keycloak

Give access to certificates:

$ chmod 0755 /etc/letsencrypt/{live,archive}
$ chgrp keycloak /etc/letsencrypt/{live,archive}
$ chgrp -h keycloak /etc/letsencrypt/live/<DOMAIN>/privkey.pem

Give access to Keycloak directory:

$ chown -R keycloak:keycloak /opt/keycloak/

Create systemd service:

$ vi /etc/systemd/system/keycloak.service

Write the following contents into the file. You might need to add your chosen database service to the After line, for example postgresql.service or mysql.service.

[Unit]
Description=Keycloak Application Server
After=syslog.target network.target

[Service]
Type=idle
User=keycloak
Group=keycloak
LimitNOFILE=102642
ExecStart=/opt/keycloak/bin/kc.sh start --optimized
StandardOutput=append:/var/log/keycloak.log
StandardError=inherit
RestartSec=2s
Restart=always
AmbientCapabilities=CAP\_NET\_BIND\_SERVICE

[Install]
WantedBy=multi-user.target

Reload systemd config and start service:

$ systemctl daemon-reload
$ systemctl start keycloak.service

4.2. Automatic Keycloak server restart when certificates are updated

Make certbot restart Keycloak after updating certificates:

$ cd /etc/letsencrypt/renewal-hooks/deploy
$ vi restart-keycloak.sh

Write these contents:

#!/bin/sh
systemctl restart keycloak

Make the script executable:

$ chmod +x restart-keycloak.sh

You're done! Now Keycloak is set up as a systemd service and will start when your machine boots up.

Try Andy's Desk

Andrés Villarreal — Sat, 15 Jan 2022 10:35:29 +0000

LINK: https://desk.glitchy.website/

This is a nostalgic (and not very faithful) recreation of the Windows 7 desktop UI.

The code is intentionally not too polished, as this is a project I work on for fun.

Things might be buggy but that's part of the fun.

You WILL find weird hacks and work-arounds and lots of inefficient stuff.

One of my main goals with this project was to build it as fast as possible. I managed this by integrating as many existing projects/code as I could find. Of course, everything is credited if you open CREDITS.txt. You can also take a look at the source code for more information!

You can find the repo here: https://github.com/KaeruCT/desk.glitchy.website

Free Static Web Hosts for Frontend Developers

Andrés Villarreal — Sat, 15 Jan 2022 09:30:31 +0000

Nowadays it's very easy to publish on the web for free.

There are countless blogging platforms and website creators. But these platforms usually end up controlling your content. Sometimes you cannot even export your own data!

The other extreme is to set up your own server by yourself. Buy a VPS (virtual private server) or a shared hosting somewhere, install a web server, and upload your files. This is a lot of work already! Specially if all you want is to publish a static website.

You already know HTML and CSS, and maybe a bit of JavaScript. You just want a place where you can drop your files and see it on the web!

Here is a list of services that allow you to do that, in no specific order:

Netlify

Netlify allows you to drag & drop a zip with your files. You can also connect it to your project from Github, Gitlab or Bitbucket. I use Netlify for a lot of my projects, such as desk.glitchy.website.

Vercel

Vercel is very similar to Netlify. They are also the company behing Next.js, so they have many integrations with it. I use Vercel for my personal website and for glitchy.website.

Surge

Surge allows you to easily publish your static website from the command line.

Github Pages

Github Pages allows you to directly from your GitHub repository. Just edit, push, and your changes are live. My blog is hosted on Github Pages.

GitLab Pages

GitLab Pages allows you to publish static websites directly from a repository in GitLab.

Closing Words

With these services, you can host your own static website for free. If having your own domain is important, then you will have to buy one, but that's the only thing you need, as many of these services allow you to use your own custom domain as well.

I recommend you familiarize yourself with the options and not to put all your eggs in one basket. The beauty of static website is that something happens to the provider, you can just copy your files to another one, and you're done! Keep it simple.