It adds the required cgi gem dependency, which is no longer part of the stdlib in Ruby 4. It also expands CI to cover all supported Ruby versions to help prevent future issues like this.
It adds the required cgi gem dependency, which is no longer part of the stdlib in Ruby 4. It also expands CI to cover all supported Ruby versions to help prevent future issues like this.
If you missed the original release, Stepped Actions is a Rails engine for orchestrating complex workflows as a tree of persisted actions that run through Active Job. It is built for long running processes, concurrency control and resuming work without losing state.
Check the docs and code at GitHub: envirobly/stepped.
Stepped is built around a few ideas that I have wanted in Rails for a long time:
concurrency_key so work runs one-at-a-time where it should.checksum can skip work that is already achieved or share currently-performing work.performing and complete it later from an external event.If you are on Rails >= 8.1.1, the install is straightforward:
gem "stepped"
This post documents what shipped along the way and why I’m pivoting toward an open source, bare metal and VPS friendly future.
rails new, AWS SDK wiring and CloudFormation EventBridge ingestion so stacks/resources could be mirrored in the app.envirobly-cli culminated in CLI v1.0.0, with UI deploy/exec snippets for copy/paste ease.
_site folder, which allows you to deploy and run a static site for free.
It seems Cloudflare is shifting focus from Pages to Workers, since the creation of a new Page app is now almost hidden, behind a small link on the bottom of a new Worker screen. Thankfully, using Workers is almost as simple.
Once you create a new worker application and connect your repo, this is how to configure it:
The important part is bundle exec jekyll build for the build command. The deploy command is the default npx wrangler deploy.
Before your first deploy, create wrangler.toml in the root of your repo with the following content:
name = "my-static-site"
compatibility_date = "2025-04-01"
[assets]
directory = "./_site/"
Important: Do not include binding if you want to keep running your site for free. That invokes worker CPU cycles, which you eventually pay for.
Also adjust Jekyll’s _config.yml to ignore this file:
exclude:
- wrangler.toml
For local previews run npx wrangler dev after a build and it will serve from _site. Add routes or a custom domain later by extending the config.
This version introduces:
To install the latest version simply:
gem install locport
This is how the listing of projects and ports used, looks in the terminal:
tmux is a terminal multiplexer. It lets you switch easily between several programs in one terminal, detach them (they keep running in the background) and reattach them to a different terminal.
I’ve been using Zellij for several months prior to this. Which I must thank for getting me introduced to the world of terminal multiplexers. However I’ve been running into several issues with it, that got me looking for an alternative:
A fantastic start into tmux are these two videos from typecraft over at YouTube. The basics are wonderfully explained there as well as some key configuration. This got me going immediately.
Here’s a documented .tmux.conf I arrived at after a day or two:
# Change leader key to something more ergonomic
# Note: On MacOS disable the shortcut to change keyboard input language first in Settings.
set -g prefix C-Space
# Allow mouse interactions like focusing windows and panes and resizing
set -g mouse on
# Simplify the status bar look: white text on black background
set -g status-style bg=black,fg=white
# Disable hostname, date and time display in the status bar
set -g status-right ""
set -g status-position top
# Use vim style navigation
set -g mode-keys vi
# Number windows starting from 1, instead of 0
set -g base-index 1
# When window is closed, refresh the numbering
set -g renumber-windows on
# Change the look of session name in the status bar
set -g status-left "#[bg=#9A7122,bold] #S #[default]#[fg=#9A7122]#[default] "
# Do not truncate session names too early
set -g status-left-length 24
# Pane borders
set -g pane-border-style fg="#5A5A5A"
set -g pane-active-border-style fg="#B3811F"
# Shortcut for live reload of tmux config
unbind r
bind r source-file ~/.tmux.conf
# Last session toggle
bind S switch-client -l
# Maximize pane
bind z resize-pane -Z
# vim like pane navigation
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R
# Set new windows and panes in the current directory
bind c new-window -c "#{pane_current_path}"
bind '"' split-window -c "#{pane_current_path}"
bind % split-window -h -c "#{pane_current_path}"
I almost forgot what I wanted to write about initially. So here’s a ready made alias I use to reload bash config across all my tmux bash sessions. This is sooo useful when I for example add something like a new alias in my .bashrc. Previously I’d have to manually source the config in each pane where I’d want to use the alias, which is a pain. Now it’s just one command:
alias reload-bash-config-in-bash-panes=$'tmux list-panes -a -F \'#{session_name}:#{window_index}.#{pane_index} #{pane_current_command}\' | awk \'$2 == "bash" {print $1}\' | xargs -I{} tmux send-keys -t {} "source ~/.bashrc" C-m'
This ensures the source command is only executed in panes that are running “bash”. It won’t affect your neovim instances for example, or other programs where it could cause unintended consequences.
In Zellij, layouts are build in and a wonderful feature. In tmux land, there is tmuxinator - a separate program - that handles layout definition via YAML files and starting sessions based on those layouts. It’s simple and I got going with it immediately.
Here’s a layout I use to run this blog in development environment:
name: klevo
root: ~/projects/klevo
windows:
- edit:
layout: main-vertical
panes:
- #bash
- nvim
- server:
layout: even-horizontal
panes:
- docker compose up
- ruby -rwebrick -e'WEBrick::HTTPServer.new(:Port => 8083, :DocumentRoot => ("#{Dir.pwd}/_site")).start'
tmux and neovim are the two things I wish I learned much earlier in my career. Mastering these tools provided an immense ergonomic boost to my workflows. It’s a joy to fly through projects and tasks in a fast, consistent, repeatable and simple environment, exactly suited to my needs.
Simple, elegant, just a touch of color for the session name.
I’ll show you how to do this, both with an already deployed app, as well as if you haven’t run “kamal setup” just yet.
There will be a short downtime (couple of seconds) while you do the switch. So plan for that.
All we need to do is to recreate the kamal Docker network, which is created with IPv4 support only, by Kamal. The problem is, you can’t remove a Docker network if containers are attached to it.
Here’s a script that reconnects the containers to a temporary network, recreates kamal network with IPv6 support, connects the containers back to it and cleans up. During this, there will be a few seconds of a downtime, as your containers will briefly loose connection to the network and/or between each other.
#!/usr/bin/env bash
set -euo pipefail
OLD_NET="kamal"
TEMP_NET="kamal_tmp_v6"
echo "Collecting containers connected to network '$OLD_NET'..."
CONTAINERS=$(docker network inspect "$OLD_NET" -f '{{range .Containers}}{{.Name}} {{end}}')
if [ -z "$CONTAINERS" ]; then
echo "No containers found on network '$OLD_NET'."
exit 1
fi
echo "Creating temporary IPv6-enabled network '$TEMP_NET'..."
docker network create \
--ipv6 \
"$TEMP_NET"
echo "Connecting containers to temporary network..."
for c in $CONTAINERS; do
echo " → Connecting $c to $TEMP_NET"
docker network connect "$TEMP_NET" "$c"
done
echo "Disconnecting containers from old network '$OLD_NET'..."
for c in $CONTAINERS; do
echo " → Disconnecting $c from $OLD_NET"
docker network disconnect "$OLD_NET" "$c" || true
done
echo "Removing old network '$OLD_NET'..."
docker network rm "$OLD_NET"
echo "Recreating network '$OLD_NET' with IPv6 enabled..."
docker network create \
--ipv6 \
"$OLD_NET"
echo "Reconnecting containers to new '$OLD_NET'..."
for c in $CONTAINERS; do
echo " → Connecting $c to $OLD_NET"
docker network connect "$OLD_NET" "$c"
echo " → Disconnecting $c from $TEMP_NET"
docker network disconnect "$TEMP_NET" "$c" || true
done
echo "Cleaning up temporary network '$TEMP_NET'..."
docker network rm "$TEMP_NET"
echo "✅ IPv6 successfully enabled on '$OLD_NET' and containers reattached."
Copy it anywhere on your server, for example ~/enable_ipv6_on_kamal.sh, make it executable and run it:
chmod +x enable_ipv6_on_kamal.sh
# Run it
./enable_ipv6_on_kamal.sh
You’re done. After a few seconds you should be able to access your app, as kamal-proxy succeeds with it’s health checks.
This is easier. On the host, just create the Docker network Kamal expects manually, and Kamal will use that once you start deploying.
docker network create --ipv6 kamal
That’s all! Now you can run kamal setup from your developer machine and you’ll have IPv6 connectivity from and to your containers right away.
]]>After an hour or two of debugging, I figured out an easy way to enable it. This is tested on Ubuntu 24.04 LTS:
sudo rm /etc/default/grub.d/40-force-partuuid.cfg
sudo update-grub
sudo grub-mkconfig -o /boot/grub/grub.cfg
# On the next reboot initramfs will run
sudo reboot
Enjoy.
]]>It runs the full lifecycle of application infrastructure on AWS. It connects to a customer’s AWS account, lays down regional foundations (VPC, NAT, Traefik gateways, Route53 DNS, Managed Prometheus), and lets teams ship services, databases, and gateways with zero-downtime deploys, live logs and metrics.
All of it done on pure EC2 instances, with custom AMI, without relying on expensive AWS services, like load balancers, RDS or paid VPC features.
envirobly) for deploy/exec, Turbo-powered UI for live status, GoodJob-backed background orchestration, and Solid Cache-backed caching.Envirobly links to your AWS account in seconds with a UI prompt and CLI handshake so foundations can be created in your own cloud.
Stepped actions show each CloudFormation and validation step so you always see progress on long-running provisioning work.
Projects capture per-region foundations, while environs hold the services and routing that map to real deployments.
Source builds and remote containers deploy via the envirobly CLI, with status mirrored in the UI.
Service views cover routing, scaling, metrics, logs, usage, backups, and custom domains—all backed by the AWS primitives noted above.
