Software Engineering News from Bruno Bernardino

Announcing Uruky

Sun, 15 Feb 2026 00:00:00 GMT

For the last couple of months I've been working with my wife on Uruky. It's a EU-based and simpler Kagi alternative (privacy-focused and ad-free search with domain boosting/exclusion rules).

We've been using it with friends and family with much success and hashbangs work for any edge cases we haven't fixed/improved yet.

It's already using EU-based search providers with EU-based indexes like Mojeek and Marginalia. We're currently waiting for EUSP (the new Ecosia/Qwant-effort-related index) to provide us with an API key.

If you're interested in trying it for a few days and are a human, reach out with your account number and I'll give you a couple of weeks for free.

If you have any suggestions, comments, or recommendations, I'd love to hear it.

Thank you for your attention and kindness. I really appreciate it!

Step-by-step guide for upgrading PostgreSQL Docker containers

Mon, 09 Jun 2025 00:00:00 GMT

Recently I upgraded a couple of apps which were running an outdated [PostgreSQL](https://www.postgresql.org/) database with [Docker](https://www.docker.com/) containers (I use [Docker Compose](https://docs.docker.com/compose/) to manage them), and had a hard time finding a good guide on how to do it. Most were too complicated, outdated, or just unnecessarily complex for me. The process should be really simple, and I had done it before, but I believe in the power of checklists, and somehow, I didn't have one handy. So I decided to write one, and share it with you here! _**NOTE:** This guide assumes the easiest way to upgrade the PostgreSQL is to export the database, start a new container, and import the database into it. This is the easiest way, but it's not the only way. You can find [other, more complicated and complex ways to do it officially](https://www.postgresql.org/docs/current/upgrading.html), but if your database isn't over ~50GB, this is the easiest and simplest way in my opinion._ ## Step 1: Dump the database First, we need a dump of the database. We'll need it to seed the new container. We don't need to stop the container for this, as we'll be using [`pg_dump`](https://www.postgresql.org/docs/current/app-pgdump.html). ```bash docker exec -it pg_dump -U

> db_backup.sql ``` ## Step 2: Stop the container Now we need to stop the container, so we can upgrade the PostgreSQL version. ```bash docker compose stop ``` ## Step 3: Upgrade the PostgreSQL version Now we need to upgrade the PostgreSQL version. Assuming you were, for example, running PostgreSQL 15 and you want to upgrade to 17, you would make the following changes to the `docker-compose.yml` file: ```diff + image: postgres:17 - image: postgres:15 ``` > **NOTE:** If you're upgrading from <18 to >=18, you might need to also [change the mounted pgdata volume as per the documentation](https://hub.docker.com/_/postgres#pgdata). It changed from `/var/lib/postgresql/data` to `/var/lib/postgresql//docker`. ## Step 4: Start the container Now we need to start the new container, running the new PostgreSQL version. ```bash docker compose up -d ``` ## Step 5: Import the database Now we need to import the database into the new container. ```bash cat db_backup.sql | docker exec -i psql -U

``` That's it! I hope this helps you. Thank you so much for being here. I really appreciate you!

Bash script for daily backups from PostgreSQL Docker containers

Thu, 29 May 2025 00:00:00 GMT

I use [Docker](https://www.docker.com/) with [Docker Compose](https://docs.docker.com/compose/) for my own apps. I've got a few apps that use [PostgreSQL](https://www.postgresql.org/), and a couple of years ago I was looking for a way to backup the databases from those containers in an easy and automated way. I found a few solutions, but all were way too complicated or inefficient or required more work to restore, or were reliant on the host machine having PostgreSQL installed (which I didn't want because my apps are running different PostgreSQL versions), so I wrote a script myself! I've been using this bash script to backup the databases from the containers. It's a simple script that runs every day at a specific time (via a simple cron job), and backs up the databases to a specific directory (via [`pg_dump`](https://www.postgresql.org/docs/current/app-pgdump.html)), without any passwords in the script. It keeps 14 days of backups, compresses them, and cleans up old backups. Oh, and it supports multiple containers! Here it is: ### `backup.sh` ```bash #!/bin/bash # # Backup Postgresql databases into daily files for multiple containers. # # Base backup settings BASE_BACKUP_DIR=/home/www/backups DAYS_TO_KEEP=14 FILE_SUFFIX=_backup.sql # App container names declare -A CONTAINERS=( ["amazing-app"]="/home/www/apps/amazing-app" ["another-app"]="/home/www/apps/another-app" ) # Common PostgreSQL settings POSTGRES_USER=postgres POSTGRES_CONTAINER_USER=postgres # Function to backup a single container backup_container() { local container_name=$1 local container_dir=$2 local backup_dir="${BASE_BACKUP_DIR}/${container_name}" local file=$(date +"%Y%m%d%H%M")${FILE_SUFFIX} local output_file="${backup_dir}/${file}" local postgres_container="${container_name}-postgresql-1" local postgres_db="${container_name}" # Create backup directory if it doesn't exist mkdir -p "${backup_dir}" # Do the database backup (dump) cd "${container_dir}" && docker exec -u ${POSTGRES_CONTAINER_USER} ${postgres_container} pg_dump --dbname="${postgres_db}" --username="${POSTGRES_USER}" > "${output_file}" # gzip the database dump file gzip "${output_file}" # Show the result echo "${output_file}.gz was created:" ls -l "${output_file}.gz" # Prune old backups for this container find "${backup_dir}" -maxdepth 1 -mtime +${DAYS_TO_KEEP} -name "*${FILE_SUFFIX}.gz" -exec rm -f '{}' ';' } for container_name in "${!CONTAINERS[@]}"; do echo "Backing up ${container_name}..." backup_container "${container_name}" "${CONTAINERS[$container_name]}" done echo "Done backing up databases." ## Restore: # cd ${container_dir} && docker cp /home/www/backups/${postgres_container}/*_backup.sql.gz ${postgres_container}:/tmp/backup.sql.gz # docker exec -u ${POSTGRES_CONTAINER_USER} -i ${postgres_container} pg_restore -C --dbname="${postgres_db}" --username="${POSTGRES_USER}" /tmp/backup.sql.gz ``` Obviously there are some things you can improve, like adding support for multiple databases per container, multiple postgresql container names (per container), and multiple postgresql users. I don't need that, so it'd be unnecessary complexity for me. I run this with a simple cronjob: ```bash # Every day at 3:07am 7 3 * * * /home/www/scripts/backup.sh > /home/www/logs/backup.log 2>&1 ``` Which keeps a nice log of the last daily backup in `/home/www/logs/backup.log`. I hope this helps you. Thank you so much for being here. I really appreciate you!

Announcing bewCloud

Sat, 16 Mar 2024 00:00:00 GMT

tl;dr; Check out more information about the project at bewCloud.com!

For the last month or so I've been working on bewCloud, and today I'm making its source code public and open!

Today I also archived quite a few projects that weren't making me much money after deciding to focus on building something for myself, long-term.

You can read more about it in its dedicated website.

If you have any suggestions, comments, or recommendations, I'd love to hear it.

Thank you for your attention and kindness. I really appreciate it!

How to forward email to multiple addresses with Cloudflare Email Routing

Sun, 10 Sep 2023 00:00:00 GMT

[Cloudflare](https://cloudflare.com) is pretty great. I use them as [a registrar](https://www.cloudflare.com/products/registrar/) and [DNS provider](https://www.cloudflare.com/application-services/products/#security-services) (not usually proxied, unless I'm actively preventing a DDoS), and recently had to move in a few domains I use mostly for email forwarding that had a specific forwarder to a couple of different email addresses. While [Cloudflare Email Routing](https://developers.cloudflare.com/email-routing/) is simple and easy to setup for any number of one-to-one email forwarding policies, you [can't choose more than one email as the destination (email forwarded to)](https://community.cloudflare.com/t/feature-email-routing-multiple-catch-all-addresses/333153). This was blocking me, but I was motivated to get all my domains under Cloudflare, so I looked into their [Email Workers](https://developers.cloudflare.com/email-routing/email-workers/) and found I could use them for that exact purpose, easily! Basically, I just create a new Email Worker, and have the Email Routing send to that worker instead of a single email address. Here's the simple code for the Email Worker: ```js export default { async email(message, env, ctx) { await message.forward('email1@example.com'); await message.forward('email2@example.com'); }, }; ``` And that's it! Nothing more. **NOTE**: You can reuse the same email worker across domains, which is exactly what I did. Had I known I couldn't rename the email worker after it was created, I'd given it a name based on where it was redirecting _to_, rather than where it was redirecting _from_. I'm sure my OCD won't make me create a brand new email worker with the same code and a different name for it to make more sense. Certainly. Anyway, I hope this helps you. Thank you so much for being here. I really appreciate you!

Migrating from Edge Cloud Computing to self-hosting with Caddy and Docker

Sat, 08 Jul 2023 00:00:00 GMT

In my quest to improve my privacy and control over the things I create and share, in the last few months I've achieved a couple of important milestones I had my sight on for a while: 1. Having my own git server, for my personal and private repos/apps/configs. 2. Deploy apps on my own server, simply. The first one was an important step in achieving the second, because I didn't want to keep my personal server settings/configs and keys in GitHub or Gitlab (somewhere I didn't control), so I've always had them backed up in an encrypted format in my home server and a couple of external disks (and cloud). The main contenders were Gitlab and [Gitea](https://gitea.com), and Gitea won because it's much lighter and faster to run (and simpler). Additionally, I found its Actions easier to setup and get working (especially for some personal repos I migrated from GitHub). After I got that going with, effectively, a couple of `docker-compose.yml` files (I already had one for my personal Nextcloud instance) and a `Caddyfile` ([`caddy`](https://caddyserver.com) is so much better than `nginx` and comes with automated certificate handling for SSL) to properly reverse proxy domains to the right docker containers, I had a nice boilerplate for my apps server, too. Since most of what I build personally nowadays is with [Deno](https://deno.land), I've had most of these apps deployed on [Deno Deploy](https://deno.com/deploy) with a lot of ease. While I have found it to be a bit too unstable (I've had apps stop working because they released a new engine version that wasn't backwards-compatible more than a couple of times, for example) and with slower cold starts than what I would expect, my main reason for getting the apps into my own server was to have more control of them. The fact they load much more faster now is a bonus. So what I've had to do in these repos, is basically create a `docker-compose.yml` file and a `Dockerfile` so that `docker-compose up` brings the app up and running. Those are simple. The `Dockerfile`: ```Dockerfile FROM denoland/deno:alpine-1.34.1 EXPOSE 8000 WORKDIR /app # Prefer not to run as root. USER deno # These steps will be re-run upon each file change in your working directory: ADD . /app # Compile the main app so that it doesn't need to be compiled each startup/entry. RUN deno cache --reload main.ts CMD ["run", "--allow-all", "main.ts"] ``` The `docker-compose.yml`: ```yaml version: '3' services: website: build: . restart: always ports: - 127.0.0.1:3000:8000 ``` Each app does require me to use a specific port, which I keep track of in a repo for my server settings/config/keys. I only open it up to the localhost (`127.0.0.1`) so that you can't access the app without `caddy` in front of it. I want that mostly for SSL, but also to potentially [throttle/rate-limit](https://caddyserver.com/docs/modules/http.handlers.rate_limit) more easily. The server's `Caddyfile` entry for such a Deno app is simple too: ```caddy example.com { tls you@example.com encode gzip zstd reverse_proxy localhost:3000 { header_up Host {host} header_up X-Real-IP {remote} header_up X-Forwarded-Host {upstream_hostport} } } ``` And that's it. Now I have complete control over the Deno version/engine running the app, and can use dynamic imports or even `npm:` specifiers if I wished (though I don't). To have it be deployed automatically on a push to the `main` branch, I have a `.gitea/workflows/deploy.yml` action, which basically SSH's into the server (I've created a key for it, shared with the apps server), pulls the `main` branch, and restarts the docker container(s). It only looks complicated because of the SSH setup, but in reality it's simple: ```yaml name: Deploy on: push: branches: - main workflow_dispatch: jobs: deploy: runs-on: ubuntu-latest steps: - uses: https://gitea.com/actions/checkout@v3 - name: Configure SSH run: | mkdir -p ~/.ssh/ echo "$SSH_KEY" | tr -d '\r' > ~/.ssh/server.key chmod 600 ~/.ssh/server.key cat >>~/.ssh/config <

Migrating a Node/NPM package to Deno

Sun, 01 Jan 2023 00:00:00 GMT

tl;dr; You can see the main commit of the migration here. You can also see the whole repo and inspect at will.

Why migrate?

I've wanted to write a package that's published in both NPM and Deno, but wanted to focus on the development and publishing process rather than the package itself, so migrating an existing package made a lot more sense.

Why shurley?

Even though it didn't have any production dependencies already, the development dependencies still required security updates, which was annoying as it didn't affect anyone using the package. Anyway, it's a very simple package/function, so it seemed like the perfect candidate for my intentions.

Why Deno?

It allows TypeScript by default, and it includes a formatter, linter, and test commands (the devDependencies that I had installed)!

What changed?

You can see it in the commit, I removed a lot of stuff. Mainly everything that enabled prettier, eslint, and mocha.

I then added a new script, build-npm.ts, which uses dnt to generate the Node-compatible code for npm.

Finally, I just added a Makefile and tweaked the README.md to make the development and publishing process easer.

I was really happy and surprised with how easy the process was, though arguably this was a very simple package to migrate.

You can find the package in Deno and in NPM now.

I hope you enjoy it.

Thank you so much for being here. I really appreciate you!

Simple Browser Message Encryption

Fri, 30 Dec 2022 00:00:00 GMT

tl;dr; You can encrypt and decrypt messages securely here. You can also see the simple code for it.

Why AES-GCM-256?

Because it's a very secure symmetric cryptographic algorithm that is natively supported in Browsers and in Deno.

Why for the browser?

Because you generally have it in every device. Note this is also a PWA that works offline, so you can install it and use it to encrypt/decrypt messages even without a network connection in most devices.

Why not just use Signal or Threema?

Ignoring the problem of having to trust an entity, sometimes people just don't have it.

Why not just use PGP?

I prefer it whenever I can, but it's not trivial to setup and use for non-technical people. Its assymetric encryption nature is much better.

But you still need to securely share the encryption password.

Indeed. And you can do it in person once, or perhaps describe it to the other person (e.g. "use my phone number" or "use your email address") instead of sharing it explicitly.

Anyway, I hope you enjoy it.

Thank you for your attention and kindness. I really appreciate it!

Using TypeScript and Web Components without bundling, with Deno

Tue, 02 Aug 2022 00:00:00 GMT

tl;dr; You can see an example of using a Web Component in my simple Deno website boilerplate. You can also see the code for it.

Why Deno?

It's no surprise I've been quite enamored with Deno and the old-school techniques of building apps and websites, especially the idea of not bundling and not using frameworks.

There's a lot to like, from the lack of large dependencies (in number and size), to the speed of deployment (it's literally up and available in production in a few seconds, as there's no build step!). It's also incredibly easier to maintain.

Why TypeScript?

Budget Zen and Loggit are currently built with Deno and both started off from my simple Deno website boilerplate, but as I converted the apps from Next.js to Deno and vanilla JavaScript, I did lose the benefits from TypeScript, which meant I wanted to eventually bring back those benefits to the client-side code.

Still, I didn't want to introduce a build or bundling step, and since Deno is always server-rendered, I just needed to transpile the TypeScript into JavaScript once the browser requested those files. Luckily, such a project already existed, and while I ended up building a simplified version, it was helpful in getting me what I needed.

Why Web Components?

Then, one arguable benefit from React and other user interface libraries (or frameworks), is that you can build reusable components, but I've found React to quickly lose performance on more complicated UIs, and I don't like all the boilerplate and client-side code it requires, so, as expected, I looked into Web Standards, and that's where Web Components are helpful and beautiful!

Web Components are perfect... web components! You can easily extend an HTML element which modern browsers will interpret without problems, potentially and easily add shadow DOM styles (so they don't clash with global styles), and also local JavaScript.

If you give it a try, you'll see you can get a lot of the benefits people generally associate with React or Vue, without any library!

By allowing Just-In-Time (JIT) TypeScript transpile, we can then build a really nice Web Component, like what I have in my simple Deno website boilerplate, (and this is how it's loaded).

Easy, right?

I hope you enjoy it.

Thank you for your attention and kindness. I really appreciate it!

Convert 1Password .1pux export file to .csv

Sun, 19 Dec 2021 00:00:00 GMT

tl;dr; You can check out the package I published here.

For the last 6 months, since Apple forced me to ditch them entirely (because they were the true owners of my devices, and due to many privacy and security breaches), I've been re-evaluating all the software I use and try to replace it with end-to-end encrypted Open Source, ideally built by "small tech". In the process, I noticed that 1Password changed their export format, and in order to test other tools, I had to easily convert it to CSV. So I built a simple CLI tool that takes their new .1pux files and converts them to .csv (and you can use the exposed functions and types to parse and export directly to whatever you want/need). It's suprisingly named 1pux-to-csv.

You can find it in NPM and in GitHub, along with instructions on how to use it.

I hope it adds value to your life.

Thank you so much for being here. I really appreciate you!

P.S.: If you're wondering why there hasn't been an "update" here for almost half a year, it's because I've been focusing on art, more than engineering software, on my free time.