Forem: Zil Norvilis

n8n vs ByteChef: Which Automation Engine Should You Self-Host?

Zil Norvilis — Sun, 24 May 2026 18:10:41 +0000

Automating the "glue work" of a SaaS business is a survival skill for a solo developer. You need to sync Stripe payments to your database, send Discord alerts for new sign-ups, and maybe trigger AI summaries for incoming emails.

For a long time, n8n has been the undisputed king of self-hosted automation. It’s the tool I’ve recommended for years because it lets you escape the high costs of Zapier while keeping your Rails monolith clean.

But recently, a new challenger called ByteChef has started gaining traction in the open-source community. It promises a more "developer-first" approach to low-code integrations.

If you are looking to set up an automation server on a $5 VPS this weekend, which one should you choose? Here is the breakdown.

1. n8n: The Versatile Giant

n8n is the "Photoshop" of automation. It is built on Node.js and uses a beautiful, flexible node-based interface where you can drag and drop connections in any direction.

The Strength: The Ecosystem
In 2026, n8n has over 400 native integrations. Whether you need to talk to a niche Lithuanian shipping API or a major player like OpenAI, n8n probably already has a node for it.

The Coder’s Edge: JavaScript Nodes
If a built-in node doesn't do exactly what you want, you can drop in a "Code Node" and write raw JavaScript. Since n8n runs on Node.js, you have access to the entire NPM ecosystem.

// A simple n8n code node example
const items = $input.all();

for (let item of items) {
  item.json.slug = item.json.name
    .toLowerCase()
    .replace(/ /g, '-');
}

return items;

The Catch: Because n8n is so flexible, complex workflows can eventually look like a "bowl of spaghetti" with wires crossing everywhere.

2. ByteChef: The Structured Alternative

ByteChef is the newer kid on the block. While n8n focuses on the "Canvas" feel, ByteChef is built with a focus on Integration Management. It’s designed for people who want to build and manage hundreds of different integrations without losing their mind.

The Strength: Multi-Step Logic and Performance
ByteChef is built on a Java-based stack (Spring Boot), which makes it incredibly performant for heavy data processing. It feels more "rigid" than n8n, but in a way that encourages better organization. It’s less of a "playground" and more of an "engine."

The Coder’s Edge: Component Building
ByteChef allows you to build your own components using a very structured schema. If you are an engineer who likes to define strict inputs and outputs for your automations, ByteChef's approach will feel very professional.

The Catch: The community is much smaller. You might find yourself having to write custom connectors for services that n8n already supports out of the box.

Side-by-Side Comparison

Feature	n8n	ByteChef
Language	Node.js (JavaScript)	Java / TypeScript
UI Vibe	Infinite Canvas (Freeform)	Structured Workflows
Integrations	400+ (Huge)	Growing
Self-Hosting	Very Easy (Docker)	Easy (Docker)
Custom Code	JavaScript everywhere	TypeScript / Java

Why I’m Sticking with n8n (For Now)

As a solo developer using the "One-Person Framework" philosophy, n8n is still the winner for 2026.

Community Support: If you have a weird error in an n8n workflow, a quick Google search usually finds a forum post with the solution. ByteChef is still building that knowledge base.
The "Vibe" Factor: n8n's visual debugging is incredible. You can see the data moving through the wires in real-time. When you're "Vibe Coding" with AI assistance, being able to see the failure point instantly is a huge time-saver.
Low Overhead: If you are already a web developer, you probably know enough JavaScript to fix anything in n8n. Learning the ByteChef component structure feels like a bigger "homework" assignment.

Summary

Choose n8n if you want the most reliable, well-documented, and flexible tool available. It is perfect for 99% of solo-dev automation needs.
Choose ByteChef if you are building an automation-heavy product where you need to manage complex, high-performance data pipelines and you prefer a more "engineered" feel over a "drawing" feel.

Regardless of which tool you pick, the most important thing is to stop writing custom Ruby scripts for third-party integrations. Get those tasks out of your Rails app and into a dedicated automation engine.

Distributed Uniqueness: Implementing Twitter Snowflake IDs in Rails 8

Zil Norvilis — Sat, 23 May 2026 17:50:24 +0000

When you run rails generate model, Rails defaults to using a standard auto-incrementing integer for your primary keys. Your first user is ID: 1, your second is ID: 2, and so on.

For a long time, this was fine. But as you grow, auto-incrementing IDs become a problem for two reasons:

Security: A competitor can see you only have 500 orders by looking at the URL /orders/500. They can even "scrape" your entire database by just incrementing the ID in the URL.
Distributed Systems: If you ever need to scale to multiple databases or allow offline creation (like in a mobile app), two different databases might try to assign ID: 501 to different things at the same time.

Many developers switch to UUIDs to fix this. But UUIDs are huge, they are slow to index in Postgres, and they look ugly in URLs (/users/550e8400-e29b-41d4-a716-446655440000).

In 2026, the "Goldilocks" solution for the solo developer is the Snowflake ID.

What is a Snowflake ID?

Originally created by Twitter, a Snowflake ID is a 64-bit integer that is guaranteed to be unique without needing a central "counter" in the database.

The magic is in how the 64 bits are broken down:

41 bits for a timestamp (gives you ~69 years of IDs).
10 bits for a "Worker ID" (identifies which server generated the ID).
12 bits for a sequence number (allows 4,096 IDs per millisecond, per server).

Because the first part of the ID is time, Snowflake IDs are roughly time-ordered. This makes them much faster for databases to index than random UUIDs.

STEP 1: The Ruby Implementation

You don't need to write the bit-shifting logic yourself. There is a great, lightweight gem called snowflake_id.

Add it to your Gemfile:

gem 'snowflake_id'

You can now generate an ID anywhere in Ruby:

SnowflakeId.generator.next_id
# => 1782345678912345678 (A clean, big integer)

STEP 2: Making it the Primary Key in Rails

To use Snowflake IDs as your primary keys, we need to tell Rails to stop using auto-increment and instead generate a Snowflake ID before saving the record.

First, create a Concern to make this reusable across all your models.

# app/models/concerns/has_snowflake_id.rb
module HasSnowflakeId
  extend ActiveSupport::Concern

  included do
    # Set the ID before the record is created in the DB
    before_create :assign_snowflake_id
  end

  private

  def assign_snowflake_id
    self.id ||= SnowflakeId.generator.next_id
  end
end

STEP 3: The Migration

When you generate a new model, you need to tell the migration not to use auto-increment.

# db/migrate/20260101000000_create_posts.rb
class CreatePosts < ActiveRecord::Migration[8.0]
  def change
    # id: false stops the default auto-increment
    create_table :posts, id: false do |t|
      t.primary_key :id, :bigint, primary_key: true
      t.string :title
      t.timestamps
    end
  end
end

Then, in your model:

class Post < ApplicationRecord
  include HasSnowflakeId
end

Why this is a Win for Solo Devs

1. Cleaner URLs

Your URLs go from /posts/123 (insecure) or /posts/550e8400... (ugly) to /posts/4829104928172349. It looks professional and hides your business volume from prying eyes.

2. Native Performance

Because it's just a bigint (a 64-bit integer), PostgreSQL handles it natively and extremely fast. It takes up half the space of a UUID, which keeps your database smaller and your backups faster.

3. Frontend Friendly

Since it’s just a number, JavaScript handles it easily (though be careful with very large numbers in JS - always return them as strings in your JSON API to avoid precision loss!).

Summary

Snowflake IDs give you the best of both worlds: the distributed uniqueness of a UUID and the performance of an integer.

If you are building a new Rails 8 app today, consider ditching auto-increment on day one. It’s one of those architectural choices that makes your app feel like a "real" enterprise product from the very first commit.

The Vibe Coder’s Survival Guide: Concepts You Can’t Just Prompt Away

Zil Norvilis — Wed, 20 May 2026 23:16:59 +0000

We are living in a wild time for software development. With tools like Cursor, Windsurf, and ChatGPT, you can "vibe" your way into a working application without knowing how to write a single line of CSS or Ruby from scratch.

But I have noticed a pattern: Vibe coding works until it doesn't.

The moment the AI makes a mistake, or your app gets a weird error, you hit a wall. If you don't understand the underlying concepts, you can't tell the AI how to fix the mess it made. You become a "Prompt Monkey" - just typing instructions and hoping for the best.

To be a truly successful Vibe Coder (or what I call an Editor-in-Chief), you need to understand 5 core concepts. You don't need to memorize the syntax, but you need to understand the "Why."

LEVEL 1: State (The Memory)

The most important question in any app is: "What does the computer remember right now?"

Imagine your app is a person.

Local State: This is like a thought in the person's head. If they go to sleep (refresh the page), they forget it.
Global/Database State: This is like a note written in a notebook. Even if the person dies (the server restarts), the information is still there.

Why this matters for Vibes: If you ask the AI to "Change the user's name," but you don't specify if it should change it in the Browser or the Database, the AI might choose the wrong one. You’ll see the name change on the screen, but it will revert back the moment you refresh.

LEVEL 2: Control Flow (The Path)

AI is great at writing logic, but it doesn't always understand the "Path" a user takes. Control flow is just a fancy way of saying "If this happens, do that."

if user.subscribed?
  show_video
else
  redirect_to_pricing_page
end

Why this matters for Vibes: When your app has a bug, it’s usually because the "Path" is broken. You need to be able to look at the code and say: "Wait, the AI is checking if the user is an admin BEFORE it checks if the user is even logged in." Identifying the order of logic is a human job.

LEVEL 3: The Request/Response Cycle (The Mailman)

This is where most Vibe Coders get stuck. They try to run a database query inside a JavaScript file that lives in the browser.

The Golden Rule:

Frontend (The Browser): This is the "Face." It handles what things look like and clicking buttons. It cannot talk to the database directly.
Backend (The Server/Rails): This is the "Brain." It has the keys to the vault (The Database).

Why this matters for Vibes: If the AI gives you code that doesn't work, check where it put the code. If it’s trying to send an email from a file in app/javascript, it will fail because the browser isn't allowed to send emails. You have to tell the AI: "Move this logic to the controller."

LEVEL 4: Data Shapes (Arrays and Hashes)

You don't need to know how to sort an array, but you need to know what they look like.

Array: A simple list. ["Apple", "Banana", "Orange"]
Hash (or Object): A dictionary with keys. { name: "Zil", country: "Lithuania" }

Why this matters for Vibes: When the AI says "Error: undefined method [] for NilClass," it usually means it expected a Hash but got nothing. You need to be able to look at the data coming from an API and see if the "Shape" matches what your code expects.

LEVEL 5: Persistence (The Database)

As a Rails dev, I love ActiveRecord. It makes the database feel like Ruby. But you still need to understand that the database is just a giant Excel spreadsheet.

Models: The name of the tab in the spreadsheet (e.g., "Users").
Rows: One specific user.
Columns: The name, email, and password.

Why this matters for Vibes: Sometimes the AI will suggest code that uses a column that doesn't exist yet (e.g., user.avatar). You need to realize: "Oh, I haven't run a migration to add the avatar column to the spreadsheet yet." The AI can't always see your database schema perfectly.

Summary: The Hybrid Workflow

Vibe coding is a superpower, but every superhero needs a mentor.

Vibe the feature: Let the AI build the first version.
Audit the State: Did it save to the DB or just the screen?
Check the Path: Is the logic in the right order?
Verify the Location: Is this a Frontend task or a Backend task?

If you understand these 5 things, you stop being a passenger and start being the pilot. You can build much more complex apps because you know how to debug the "Vibe."

The Perfect Zsh Setup: Oh My Zsh on CachyOS/Arch

Zil Norvilis — Tue, 19 May 2026 23:16:53 +0000

If you want a terminal that tells you if a command is valid, predicts what you’re about to type, and shows your Git branches, follow this clean-slate guide.

1. Install the Foundations

Before installing the framework, we need the "Holy Trinity" of Zsh plugins and a font that can handle icons.

# Install the core plugins and Git
sudo pacman -S zsh-syntax-highlighting zsh-autosuggestions git ttf-jetbrains-mono-nerd

2. Install Oh My Zsh

Run the official script to install the framework:

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

3. The "Master" Configuration (`.zshrc`)

This is the most important part. We need to tell Zsh to load the plugins from the system folders (where Arch installs them) and hook up Ruby.

Open your config: nano ~/.zshrc

Delete everything inside and paste this optimized block:

# 1. Path to Oh My Zsh
export ZSH="$HOME/.oh-my-zsh"

# 2. Theme (Agnoster is the best for Git branch visibility)
# Note: Requires a Nerd Font in terminal settings to see arrows/icons
ZSH_THEME="agnoster"

# 3. Core Plugins
plugins=(git ruby rbenv sudo archlinux)

# 4. Load Oh My Zsh
source $ZSH/oh-my-zsh.sh

# 5. Developer Tools (rbenv for Ruby)
export PATH="$HOME/.rbenv/bin:$PATH"
eval "$(rbenv init -)"

# 6. Pro Features (Syntax Highlighting & Autosuggestions)
# We source these manually to ensure they work perfectly on Arch/Cachy
source /usr/share/zsh/plugins/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh
source /usr/share/zsh/plugins/zsh-autosuggestions/zsh-autosuggestions.zsh

# 7. Helpful Aliases
alias yay='paru'
alias cls='clear'

4. Final Polish (Icons & Colors)

Fix the Icons

If you see squares instead of arrows/branches:

Open your Terminal (Konsole/Alacritty) Settings.
Go to Appearance -> Font.
Select JetBrainsMono Nerd Font.

Apply Changes

source ~/.zshrc

Why this setup is better:

✅ Green/Red Syntax

Type ls - it turns green because the command exists.
Type asdf - it turns red because the command is invalid. No more "command not found" surprises.

✅ Inline Ghost Suggestions

As you type, you'll see a gray preview of your last used command. Just hit the Right Arrow key to complete it. It's like autocomplete for your terminal.

✅ Smart Git Branches

The moment you cd into a project folder, the prompt changes to show exactly which branch you are on and if you have uncommitted changes.

✅ rbenv Integration

Ruby versions are automatically handled. If you have a .ruby-version file in a project, the shell switches to it immediately.

Pro-Tip for CachyOS Users:

CachyOS sometimes looks for your config in ~/.config/zsh/.zshrc. If your changes don't show up, run this to sync them:
mkdir -p ~/.config/zsh && cp ~/.zshrc ~/.config/zsh/.zshrc

Completing the Puzzle: Adding Signup and Password Resets to Rails 8 Auth

Zil Norvilis — Mon, 18 May 2026 23:17:29 +0000

If you’ve tried the new rails generate authentication command in Rails 8, you know it’s a breath of fresh air. It gives you a solid, secure foundation for sessions and login without the "black box" magic of Devise.

However, the generator is intentionally minimal. It gives you the "Login" and "Logout" logic, but it leaves two big holes: How do users sign up? and How do they reset their password?

Because the auth code now lives in your app/ folder, adding these features is straightforward. You don't have to learn a gem's DSL; you just write standard Rails code. Here is how to complete your authentication system in two phases.

Phase 1: The Signup Flow (Registrations)

Signing up a user is just a standard "Create" action in ActiveRecord. We just need a controller and a view.

STEP 1: The Controller

Generate a registrations controller:

rails generate controller registrations

Update the code to create a user and immediately log them in by starting a session:

# app/controllers/registrations_controller.rb
class RegistrationsController < ApplicationController
  # Allow guests to see this page!
  allow_unauthenticated_access only: %i[ new create ]

  def new
    @user = User.new
  end

  def create
    @user = User.new(user_params)
    if @user.save
      # The 'start_new_session_for' method comes from the 
      # Authenticated concern generated by Rails 8
      start_new_session_for @user
      redirect_to root_path, notice: "Welcome! You have signed up successfully."
    else
      render :new, status: :unprocessable_entity
    end
  end

  private

  def user_params
    params.require(:user).permit(:email_address, :password, :password_confirmation)
  end
end

STEP 2: The Routes and View

Add the routes to your config/routes.rb:

get  "signup", to: "registrations#new"
post "signup", to: "registrations#create"

In your view (app/views/registrations/new.html.erb), use a standard form. Remember to use email_address as the field name, as that is what the Rails 8 generator uses by default in the User model.

Phase 2: Password Resets (The Modern Way)

In the old days, we had to add a reset_password_token column to our database. In Rails 8, we can use the built-in Generates Token API to create time-sensitive tokens without extra database columns.

STEP 1: Update the User Model

Tell Rails that the User model can generate tokens for password resets.

# app/models/user.rb
class User < ApplicationRecord
  has_secure_password
  has_many :sessions, dependent: :destroy

  # Generate a token that expires in 15 minutes
  generates_token_for :password_reset, expires_in: 15.minutes do
    password_salt.last(10)
  end
end

STEP 2: The Passwords Controller

We need two main actions: create (to send the email) and update (to change the password).

rails generate controller passwords

# app/controllers/passwords_controller.rb
class PasswordsController < ApplicationController
  allow_unauthenticated_access
  before_action :set_user_by_token, only: %i[ edit update ]

  def create
    if user = User.find_by(email_address: params[:email_address])
      # Send the email (We'll make the mailer in the next step)
      PasswordsMailer.reset(user).deliver_later
    end
    # Always redirect to the same page so hackers can't "fish" for emails
    redirect_to new_session_path, notice: "If that email exists, a reset link has been sent."
  end

  def update
    if @user.update(params.permit(:password, :password_confirmation))
      redirect_to new_session_path, notice: "Password has been reset. Please log in."
    else
      render :edit, status: :unprocessable_entity
    end
  end

  private

  def set_user_by_token
    # Find the user using the token from the URL
    @user = User.find_by_token_for!(:password_reset, params[:token])
  rescue StandardError
    redirect_to new_password_path, alert: "Invalid or expired token."
  end
end

STEP 3: The Mailer

Generate a mailer to send the reset link:

rails generate mailer Passwords

# app/mailers/passwords_mailer.rb
class PasswordsMailer < ApplicationMailer
  def reset(user)
    @user = user
    # Generate the token specifically for this email
    @token = user.generate_token_for(:password_reset)

    mail to: user.email_address, subject: "Reset your password"
  end
end

In your mailer view, create the link:

<%= link_to "Reset Password", edit_password_url(token: @token) %>

STEP 4: The Routes

resources :passwords, param: :token

Why this is better than a Gem

No Hidden Logic: If your "Password Reset" email isn't sending, you can debug it in your own mailer file. You don't have to guess what a gem is doing.
Speed: You aren't loading extra middleware or heavy dependencies.
Customization: Want to add an "SMS Reset" later? Or a "Security Question"? You own the controller, so you just add the code.

Summary

The Rails 8 authentication generator is a "starter kit," not a finished product. By adding a RegistrationsController and using the generates_token_for API, you get a full-featured, enterprise-grade auth system that is 100% under your control.

Stop fighting the gems. Start writing the Ruby code.

Rails 8 Built-in Auth vs. Devise: Why the Default Finally Wins

Zil Norvilis — Sun, 17 May 2026 23:23:33 +0000

For almost 15 years, if you wanted to build a Rails app with a login system, the answer was always the same: Devise.

Devise is a legend. It is battle-tested, secure, and handles everything from "Forgot Password" to "Account Locking." But Devise also comes with a heavy price. It is a "black box" of magic. If you want to change the way a simple login redirect works, you often find yourself digging through 10 layers of documentation and overriding internal controllers that you don't even own.

With the release of Rails 8, the game has changed. Rails now has a built-in authentication generator. It isn't a "gem" that hides code from you; it is a tool that writes clean Ruby code directly into your app.

Here is why Rails 8 authentication is finally better than Devise for the solo developer.

1. Ownership vs. Magic

When you install Devise, you are adding a massive dependency. The logic for signing in, signing out, and sessions lives inside the gem’s folder, not your app.

In Rails 8, you run one command:

rails generate authentication

This command generates a Session model, a SessionsController, and an Authenticated concern. The code lives in your app/ folder.

If you want to change how the login works, you don't have to look up "Devise overrides." You just open app/controllers/sessions_controller.rb and change the code. There is no magic - just plain Ruby.

2. No More "Gem Bloat"

Devise is heavy. It brings in several other dependencies (like Warden) and adds a lot of routes and helpers to your app that you probably don't use.

As a solo developer building a "One-Person Framework" app, you want your stack to be as lean as possible. Rails 8 auth uses what is already built into the framework: has_secure_password.

It uses the standard Rails way of handling cookies and sessions. Because it is native, it works perfectly with Turbo and Mission Control without any extra configuration.

3. Rate Limiting is Built-In

One reason people stuck with Devise was for security features like "Lockable" (preventing brute force attacks).

Rails 8 handles this at the routing level. The generator automatically adds rate limiting to your login actions:

# app/controllers/sessions_controller.rb
class SessionsController < ApplicationController
  # This stops bots from trying 1,000 passwords a minute
  rate_limit to: 10, within: 3.minutes, only: :create, with: -> { redirect_to new_session_url, alert: "Try again later." }

  def create
    if user = User.authenticate_by(params.permit(:email_address, :password))
      start_new_session_for user
      redirect_to after_authentication_url
    else
      redirect_to new_session_url, alert: "Try again."
    end
  end
end

You get professional-grade security without the overhead of a massive external library.

4. Easy to Upgrade to Passkeys

As I wrote in a previous article, passwords are dying. In 2026, users want to log in with FaceID or TouchID (Passkeys).

Upgrading Devise to support Passkeys is a nightmare because you have to fight Devise's internal session handling.

Because the Rails 8 auth code is just a regular controller, adding Passkeys is simple. You just add a few lines to your SessionsController to verify the hardware signature. You don't have to ask a gem for permission to change how your users log in.

Summary: Which one should you pick?

Stick with Devise if you are working on a massive legacy app that already uses it, or if you need very complex features like "Omniauth with 10 different providers" and don't want to write any code.
Use Rails 8 Auth for every new project.

The "generator" approach is the ultimate win for the solo developer. It gives you a secure starting point, but lets you keep total control over the most important part of your app: the gateway to your users.

Build Once, Launch Ten Times: The Rails Engine SaaS Strategy

Zil Norvilis — Sat, 16 May 2026 23:06:10 +0000

If you are a solo developer with "Shiny Object Syndrome," you know the feeling. You have a great idea for a new SaaS on a Saturday morning. You run rails new, and then... you spend the next two days setting up the same boring stuff you’ve built ten times before.

You set up User Authentication. You configure Stripe or Paddle for billing. You build a "Team" model for multi-tenancy. You design a basic Sidebar and Navbar.

By Monday morning, you are exhausted, and you haven't even touched the actual "unique" feature of your new idea.

Most people solve this with Templates (copy-pasting an old project or using a starter kit). But templates have a big problem: they are a snapshot in time. If you find a bug in your billing logic, you have to manually fix it in five different projects.

In 2026, the "Pro" way to do this as a solopreneur is to build a Rails Engine.

What is a Rails Engine?

Think of a Rails Engine as a "Mini-App" that lives inside a Gem. Gems like Devise, Sidekiq, and Avo are all engines. They provide their own routes, models, and views that plug into your main application.

By building your own "SaaS Core" engine, you can update your billing logic or UI components in one place, and every project you’ve ever launched will get the update instantly.

Here is how to build your own reusable SaaS starter kit.

STEP 1: Generate the Engine

We want to create a "mountable" engine. This gives us an isolated namespace so our engine code doesn't accidentally overwrite code in our main app.

rails plugin new saas_core --mountable

This creates a new folder structure that looks like a tiny Rails app.

STEP 2: Add the "Boring" SaaS Logic

Inside your engine, you should add everything that is "standard" for your business model.

The Essentials:

Authentication: Use the Rails 8 generate authentication logic here.
Billing: Add a Subscription model and a service object to talk to Stripe or LemonSqueezy.
Multi-tenancy: Add an Account or Organization model that Users belong to.

Because this is a mountable engine, your models will be namespaced. Instead of User, you will have SaasCore::User. This is great because it prevents naming conflicts when you integrate it into a new project.

STEP 3: Shared UI (The Design System)

This is the biggest time-saver. Don't just share logic; share your UI components.

I use ViewComponent or Phlex inside my engine to build a library of standard buttons, forms, and layouts.

# saas_core/app/components/saas_core/sidebar_component.rb
module SaasCore
  class SidebarComponent < ViewComponent::Base
    def initialize(user:)
      @user = user
    end
  end
end

Now, every SaaS you build will have the exact same professional look and feel from minute one.

STEP 4: The Local Development Workflow

As a solo dev, you don't want to publish your engine to a public server every time you make a change. You want to develop it side-by-side with your new SaaS idea.

In your new SaaS project's Gemfile, point to the local path of your engine:

# my_new_idea/Gemfile
gem 'saas_core', path: '../saas_core'

And in your routes:

# my_new_idea/config/routes.rb
mount SaasCore::Engine => "/"

Now, when you edit a file in the saas_core folder, the changes show up instantly in my_new_idea.

Why this is the ultimate Solopreneur hack

1. The "Bug Once, Fix Everywhere" Rule

If you realize your GDPR cookie banner is broken, you fix it in the engine. You run bundle update in your 3 active SaaS projects, and they are all compliant again.

2. Zero-Friction Launching

When you have a new idea, your rails new process takes 10 seconds. You add your engine, and you already have a "Pro" plan, a login screen, and a beautiful dashboard. You can focus 100% of your energy on the Actual Idea.

3. Ownership

You aren't relying on a third-party "SaaS Template" that might get abandoned. You own the core of your business. As you learn new tricks (like Rails 8 Page Morphing), you add them to your engine, and your entire "Empire" gets an upgrade.

Summary

Stop starting from scratch. Stop copy-pasting messy code from your last project.

Build a Mountable Engine for your SaaS "Plumbing."
Include Auth, Billing, and Teams.
Bundle your UI into ViewComponents.
Develop locally using the path: gem option.

The goal of the "One-Person Framework" is to make you as fast as a team of ten. Building your own Rails Engine is how you achieve that speed.

Ditching Redis: How to Handle WebSockets in Rails 8 with Solid Cable

Zil Norvilis — Fri, 15 May 2026 23:06:08 +0000

Real-Time Rails Without Redis: A Guide to Solid Cable

For years, adding a single real-time feature to a Rails app felt like signing a deal with the devil.

You just wanted a simple notification bell to update without a page refresh, or a basic live chat. But the moment you decided to use ActionCable, you had to invite a completely new piece of infrastructure into your stack: Redis.

Managing Redis meant paying for another server, monitoring its memory usage, and ensuring your production environment was wired up correctly. For a solo developer trying to keep costs and complexity low, it was a massive headache.

In Rails 8, the "One-Person Framework" philosophy struck again. DHH and the Rails team decided that requiring Redis just for basic WebSockets was a mistake.

Enter Solid Cable.

Solid Cable replaces Redis by using your existing SQL database (PostgreSQL, MySQL, or SQLite) as the Pub/Sub backend for ActionCable. Here is how it works, and how to set it up in 3 simple steps.

The Mental Model: How can a Database handle WebSockets?

When you hear "Database-backed WebSockets," your first instinct as an engineer is probably panic. "Won't polling the database 50 times a second completely crash my Postgres server?"

A decade ago, the answer was yes. But hardware has evolved.

Today's servers run on blazing-fast NVMe SSDs. Furthermore, Solid Cable is incredibly optimized. It doesn't do dumb, heavy table scans. It keeps messages in a lightweight table and uses an efficient pruning mechanism to delete old messages immediately after they are broadcasted.

Unless you are building the next WhatsApp or a high-frequency trading platform, your standard PostgreSQL database (or even SQLite in WAL mode) can handle thousands of concurrent WebSocket connections without breaking a sweat.

STEP 1: Installation and Database Setup

If you generate a brand new Rails 8 app, Solid Cable is already included. But if you are upgrading an older app or adding it manually, here is the process.

Add the gem to your Gemfile:

gem "solid_cable"

Run bundle install.

Next, we need to create the table where Solid Cable will temporarily hold the WebSocket messages. Run the installation generator:

bin/rails solid_cable:install

This generates a configuration file and a database migration. Apply the migration:

bin/rails db:migrate

Note: Just like Solid Queue, Rails 8 encourages keeping this table in a separate database file or logical database (e.g., cable instead of primary) to keep your main application data isolated from the heavy read/write load of WebSockets.

STEP 2: The Configuration (`cable.yml`)

Now we need to tell ActionCable to stop looking for Redis and start using our database.

Open your config/cable.yml file. You will see different environments. Update your production (and development if you want to test it locally) to use the new adapter:

# config/cable.yml
development:
  adapter: solid_cable
  polling_interval: 0.1.seconds
  message_retention: 1.day

test:
  adapter: test

production:
  adapter: solid_cable
  polling_interval: 0.1.seconds
  message_retention: 1.day

That is literally it for the infrastructure. You have successfully deleted Redis from your application.

STEP 3: Using It (The Code Stays the Same!)

The absolute best part about Solid Cable is that it is just a backend adapter. Your frontend and backend Ruby code do not change at all. You still use the exact same Hotwire and Turbo Stream methods you already know.

Let's say we have a Comment model, and we want it to show up on the user's screen in real-time.

In the View, we listen to a channel:

<!-- app/views/posts/show.html.erb -->
<%= turbo_stream_from @post, "comments" %>

<div id="comments_list">
  <%= render @post.comments %>
</div>

In the Model, we tell it to broadcast:

# app/models/comment.rb
class Comment < ApplicationRecord
  belongs_to :post

  # When a comment is created, send the HTML over Solid Cable!
  after_create_commit -> { 
    broadcast_append_to post, "comments", 
    target: "comments_list", 
    partial: "comments/comment" 
  }
end

Behind the scenes, when broadcast_append_to is called, Rails writes a fast row to the solid_cable_messages database table. The Solid Cable worker instantly picks it up, pushes it through the WebSocket connection to the browser, and then cleans up the database row.

Summary

The entire Rails 8 era is defined by one word: Consolidation.

We got rid of Webpack by using Importmaps. We got rid of Node.js for frontend building. We got rid of Redis for background jobs with Solid Queue. And now, we have gotten rid of Redis for WebSockets with Solid Cable.

Your entire production stack can now consist of exactly two things:

A Linux Server (Running Docker/Kamal).
A Database.

By eliminating complex infrastructure, you free up your mental bandwidth to do the only thing that actually matters: building a product that people want to pay for.

The Magic of Turbo Frames: Infinite Pagination in Pure HTML

Zil Norvilis — Fri, 15 May 2026 16:47:35 +0000

Building an Infinite Scroll in Rails 8 (Zero Custom JavaScript)

Every modern web application eventually needs a feed. Whether it's a list of articles, a timeline of comments, or a gallery of products, users expect an "Infinite Scroll" experience. They scroll to the bottom, and the next batch of items magically appears.

In the past, implementing this was a nightmare for backend developers. You had to:

Write JavaScript to listen to the window scroll event (and debounce it so it didn't crash the browser).
Calculate if the user was 100 pixels away from the bottom of the screen.
Fire an AJAX request.
Parse a JSON response.
Append new DOM elements to the page.

It was messy and prone to bugs.

If you are using Rails 8, you can throw all of that JavaScript away. By combining standard Rails pagination with a powerful feature of Hotwire called Lazy-Loaded Turbo Frames, we can build a perfect infinite scroll in about 5 minutes, writing absolutely zero custom JS.

Here is exactly how to do it.

The Strategy

The concept is brilliantly simple. We are going to put our list of items inside a <turbo-frame>. At the very bottom of that list, we will put another turbo frame.

This second frame will have an attribute called loading="lazy", and its src will point to the URL of "Page 2".

When the user scrolls down, and that empty frame enters the browser viewport, Turbo automatically fetches the URL and replaces the empty frame with the contents of Page 2 (which includes the next batch of items, plus a new lazy frame pointing to Page 3).

STEP 1: The Controller

First, we need standard pagination in our controller. You can use the pagy gem or the built-in Rails limit/offset. For this example, let's use the popular kaminari gem because it is very explicit.

# app/controllers/posts_controller.rb
class PostsController < ApplicationController
  def index
    # Load 10 posts at a time based on the ?page= parameter
    @posts = Post.order(created_at: :desc).page(params[:page]).per(10)
  end
end

STEP 2: The View (The Magic Frame)

Now, open your index view. This is where the magic happens.

We need to wrap our content in a <turbo-frame> that has a dynamic ID based on the current page number. If we are on Page 1, the ID is posts_page_1.

<!-- app/views/posts/index.html.erb -->

<h1>The Infinite Feed</h1>

<!-- The main feed container -->
<div id="posts_feed">

  <!-- The dynamic Turbo Frame for the current page -->
  <turbo-frame id="posts_page_<%= @posts.current_page %>">

    <!-- Render the actual posts -->
    <% @posts.each do |post| %>
      <div class="p-4 border-b">
        <h3><%= post.title %></h3>
      </div>
    <% end %>

    <!-- The Lazy-Loading Trigger -->
    <% unless @posts.last_page? %>
      <!-- This frame points to the NEXT page and loads lazily -->
      <turbo-frame id="posts_page_<%= @posts.next_page %>" 
                   src="<%= posts_path(page: @posts.next_page) %>" 
                   loading="lazy">

        <!-- A simple loading spinner to show while fetching -->
        <p class="text-center text-gray-500 py-4 animate-pulse">Loading more...</p>

      </turbo-frame>
    <% end %>

  </turbo-frame>

</div>

How It Actually Works (Step-by-Step)

When a user visits /posts, here is exactly what happens:

Rails renders Page 1. The ID of the outer frame is posts_page_1.
At the bottom of the 10 items, there is an empty frame with id="posts_page_2" and loading="lazy".
The user scrolls down. As soon as that empty frame becomes visible on the screen, Turbo sees the loading="lazy" attribute and fires an HTTP request to src="/posts?page=2".
Rails receives the request and renders index.html.erb for Page 2.
Turbo receives the HTML response for Page 2. It looks for the frame named posts_page_2.
It extracts the contents of posts_page_2 (which contains posts 11-20, plus a new lazy frame for posts_page_3) and swaps it seamlessly into the original page.

The user experiences a buttery smooth infinite scroll, and you didn't have to write a single line of JavaScript.

STEP 3: Optimization (The Pro Move)

The code above works perfectly. However, there is one small performance optimization we should make.

When Turbo requests Page 2, Rails is rendering the entire index.html.erb layout (including your navbar, footer, and sidebars). Turbo is smart enough to throw away the navbar and only use the specific <turbo-frame>, but rendering that extra HTML on the server wastes CPU cycles.

We can tell our Rails controller to skip the application layout if the request is coming from a Turbo Frame.

# app/controllers/posts_controller.rb
class PostsController < ApplicationController
  def index
    @posts = Post.order(created_at: :desc).page(params[:page]).per(10)

    # If Turbo is asking for this page (e.g. infinite scroll), 
    # don't render the heavy application layout.
    if turbo_frame_request?
      render partial: "posts/page", locals: { posts: @posts }
    end
  end
end

(You would then extract the turbo-frame logic from Step 2 into a _page.html.erb partial).

Summary

This is the beauty of the modern Rails 8 stack. By understanding how HTML over the wire works, you can delete entire categories of frontend complexity.

You don't need a Javascript Intersection Observer.
You don't need to parse JSON.
You just use a <turbo-frame> with loading="lazy".

As a solo developer, finding these "low-code" solutions is the only way to ship features fast enough to compete. Keep it simple, and let the browser do the heavy lifting.

Why I Stopped Using Stripe: The Case for Merchant of Records (MoR)

Zil Norvilis — Wed, 13 May 2026 23:23:37 +0000

If you are building a SaaS in 2026, the default advice is always the same: "Just plug in Stripe and launch."

Stripe is an incredible piece of engineering. Their APIs are flawless, their documentation is the gold standard of the internet, and integrating Stripe Checkout into a Rails app takes about ten minutes.

For a long time, I used Stripe for everything. But as my side projects started actually making money, a dark, terrifying reality crept in: Global Tax Compliance.

As a solo developer based in Europe, I realized that taking payments globally isn't just about moving money from Point A to Point B. It’s a legal minefield. This is why I entirely stopped using Stripe for my B2C (Business to Consumer) SaaS projects and switched to using a Merchant of Record (MoR) like Paddle or Lemon Squeezy.

Here is the exact difference, and why it matters to your sanity.

The Problem: The "Tax Nexus" Nightmare

When you use Stripe, Stripe is simply a Payment Processor.

They take the credit card, they verify the funds, and they put the money in your bank account. That’s it.

Legally, YOU are the one selling the software to the customer.

Why is this a problem? Let's say you sell a $10/month subscription.

A user in Germany buys it. You owe 19% VAT to Germany.
A user in the UK buys it. You owe 20% VAT to the UK.
A user in Texas buys it. You owe Texas state sales tax.

Suddenly, because you sold software globally, you are legally required to register for taxes in multiple different countries, calculate the exact rates based on the buyer's IP address, collect the tax, and remit it to foreign governments quarterly.

If you are a One-Person Team, trying to figure out the tax laws of 50 different countries will consume your entire life. You will spend more time doing accounting than writing Ruby code. (Yes, Stripe Tax exists, but it only calculates the tax; you still have to file the paperwork yourself).

The Solution: The Merchant of Record (MoR)

A Merchant of Record (like Paddle or Lemon Squeezy) works entirely differently.

When you use an MoR, the legal flow changes.
You sell your software to the MoR. The MoR sells the software to the customer.

Because Paddle is the one officially selling the product to the user in Germany, Paddle is legally responsible for calculating, collecting, and remitting the 19% VAT to the German government.

For you, the developer, the nightmare is over. At the end of the month, Paddle sends you one single payout. As far as your local tax authority is concerned, you only made one B2B sale that month: you sold your services to Paddle (a UK company).

The Trade-Offs

Switching to an MoR feels like a magic bullet, but it does come with trade-offs you need to understand.

1. The Fees are Higher

Because an MoR handles international taxes, handles chargeback disputes, and assumes legal liability, they charge more.

Stripe: ~2.9% + 30¢ per transaction.
Paddle / Lemon Squeezy: ~5% + 50¢ per transaction.

When you are starting out, giving up 5% feels painful. But ask yourself: how much is an international tax accountant going to cost you? Usually, the 2% difference is much cheaper than hiring a professional to file VAT returns in the EU.

2. The Integration is Slightly Different

Integrating an MoR into Rails is conceptually similar to Stripe, but slightly less "native". You don't use a massive Ruby gem.

Usually, you drop their Javascript snippet onto your pricing page to trigger a checkout overlay. Then, just like Stripe, you set up a webhook endpoint in your Rails app.

# app/controllers/webhooks/paddle_controller.rb
class Webhooks::PaddleController < ApplicationController
  skip_before_action :verify_authenticity_token

  def create
    # Paddle sends a signature we must verify
    if valid_paddle_signature?(request)
      event = params[:alert_name]

      case event
      when 'subscription_payment_succeeded'
        # Upgrade the user!
        user = User.find_by(email: params[:email])
        user.update!(pro: true)
      end

      head :ok
    else
      head :unauthorized
    end
  end
end

It is very straightforward, but you will be relying more on raw webhook handling rather than a polished library.

3. Less Control Over the Checkout

With Stripe Elements, you can design a checkout flow that perfectly matches your app's brand. With an MoR, you are generally forced to use their hosted checkout pages or standard popups.

Summary

If you are a US-based developer selling exclusively to other US businesses (B2B), Stripe is still the undisputed king.

But if you are a solo developer (especially in Europe) selling B2C products globally, the math changes. Your goal is to write code and build a great product, not to become an expert in the European Union's digital VAT laws.

Giving up an extra 2% of your revenue to a Merchant of Record like Paddle or Lemon Squeezy is the best "DevOps" investment you can make. It buys you total peace of mind.

Stop Paying for Vector Databases: How to Build AI Search in Postgres

Zil Norvilis — Wed, 13 May 2026 23:07:00 +0000

I see developers trying to build "AI Chatbots" that know about their specific company data. They want the AI to read their PDFs, their internal wikis, or their past customer support tickets, and answer questions based on that data.

This technique is called RAG (Retrieval-Augmented Generation).

When the AI hype first started, developers thought they had to pay for expensive, dedicated "Vector Databases" like Pinecone or Milvus to do this. They added a massive layer of complexity to their stack just to store some AI data.

In 2026, the Rails way to do this is much simpler. You just use PostgreSQL.

By using the pgvector extension and a brilliant Ruby gem called neighbor, you can keep all your AI data perfectly synced inside your standard Rails database. You get the power of RAG without leaving the comfort of ActiveRecord.

Here is exactly how to build "Chat with your Database" in 4 steps.

The Mental Model: What are Embeddings?

Before we code, you need to understand how AI "searches" text.

AI does not read words; it reads math. When you send a paragraph of text to an AI (like OpenAI's embedding model), it returns an Embedding - a massive array of 1,536 numbers.

Think of this array as a set of coordinates on a map. Paragraphs that talk about similar things are placed closer together on this map. To search for an answer, we turn the user's question into coordinates, and ask the database: "Which paragraphs are physically closest to this question on the map?"

STEP 1: The Database Setup

First, we need to tell PostgreSQL that it is allowed to store these massive arrays of numbers. We do this by enabling the vector extension.

Add the gems to your Gemfile:

gem 'ruby-openai' # To talk to ChatGPT
gem 'neighbor'    # To add vector search to ActiveRecord

Run bundle install.

Next, generate a migration to enable the extension and add a vector column to the table we want to search (let's use a Document model).

rails g migration AddEmbeddingsToDocuments

# db/migrate/20260506120000_add_embeddings_to_documents.rb
class AddEmbeddingsToDocuments < ActiveRecord::Migration[8.0]
  def change
    # 1. Enable the Postgres extension
    enable_extension "vector"

    # 2. Add the column. OpenAI's standard models output 1536 dimensions.
    add_column :documents, :embedding, :vector, limit: 1536
  end
end

Run rails db:migrate.

Now, open your model and tell the neighbor gem to track that column:

# app/models/document.rb
class Document < ApplicationRecord
  has_neighbors :embedding
end

STEP 2: Generating the Embeddings

When a user creates a new Document in your app, we need to turn its text into an embedding and save it to the database. (Note: Because API calls are slow, you should do this in a Solid Queue background job!)

# app/services/embedding_service.rb
class EmbeddingService
  def self.generate(document)
    client = OpenAI::Client.new(access_token: ENV['OPENAI_API_KEY'])

    response = client.embeddings(
      parameters: {
        model: "text-embedding-3-small",
        input: document.content
      }
    )

    # Extract the array of 1536 floats
    vector = response.dig("data", 0, "embedding")

    # Save it directly to our Postgres column
    document.update!(embedding: vector)
  end
end

STEP 3: The Vector Search (Finding the Context)

Now for the magic. A user asks a question: "What is our company's refund policy?"

First, we must turn their question into a vector using the exact same OpenAI model. Then, we use the neighbor gem's .nearest_neighbors method to search Postgres.

# app/services/rag_search_service.rb
class RagSearchService
  def self.search(question)
    client = OpenAI::Client.new(access_token: ENV['OPENAI_API_KEY'])

    # 1. Turn the question into coordinates
    question_vector = client.embeddings(
      parameters: { model: "text-embedding-3-small", input: question }
    ).dig("data", 0, "embedding")

    # 2. Ask Postgres to find the 3 closest documents
    # "inner_product" is the fastest distance metric for OpenAI embeddings
    relevant_docs = Document.nearest_neighbors(:embedding, question_vector, distance: "inner_product").limit(3)

    relevant_docs
  end
end

Because of the neighbor gem, searching vectors feels exactly like a standard ActiveRecord query!

STEP 4: The RAG Prompt

We have the user's question, and we have the 3 documents that contain the answer. Now, we just smash them together into one giant prompt and send it to ChatGPT to generate a human-sounding response.

# app/controllers/chats_controller.rb
class ChatsController < ApplicationController
  def create
    user_question = params[:question]

    # 1. Get the relevant data from Postgres
    docs = RagSearchService.search(user_question)

    # 2. Build the context string
    context = docs.map(&:content).join("\n\n---\n\n")

    # 3. Build the RAG Prompt
    system_prompt = <<~PROMPT
      You are a helpful company assistant. Answer the user's question 
      using ONLY the context provided below. If the answer is not in 
      the context, say "I don't know."

      CONTEXT:
      #{context}
    PROMPT

    # 4. Ask the AI
    client = OpenAI::Client.new(access_token: ENV['OPENAI_API_KEY'])
    response = client.chat(
      parameters: {
        model: "gpt-4o",
        messages:[
          { role: "system", content: system_prompt },
          { role: "user", content: user_question }
        ]
      }
    )

    @answer = response.dig("choices", 0, "message", "content")

    # Render your Hotwire view here...
  end
end

Summary

The entire multi-billion dollar "RAG" industry boils down to this incredibly simple pipeline:

Text -> OpenAI -> Numbers (Saved in Postgres).
Question -> OpenAI -> Numbers.
Find closest Numbers in Postgres using neighbor.
Send Question + Found Text -> OpenAI -> Final Answer.

By leveraging pgvector and ActiveRecord, we avoid adding a completely new piece of infrastructure to our stack. Your AI data lives right next to your user data, it is backed up together, and it is queried using the same Ruby syntax you already know and love.

The "One Person Framework" strikes again.

Background AI: Using Solid Queue for Slow OpenAI API Calls

Zil Norvilis — Tue, 12 May 2026 23:07:01 +0000

Very often I see developers integrating AI into their Rails apps for the first time, and they make a critical mistake that completely destroys their server performance.

They treat the OpenAI (or Anthropic) API like a regular database query. They put the API call directly inside their controller.

# The "Server Killer" Approach
def create
  @document = Document.find(params[:id])

  # This might take 15 seconds!
  response = OpenAiClient.generate_summary(@document.text)

  @document.update(summary: response)
  redirect_to @document
end

When you do this, the Puma web thread handling that user's request freezes. It sits there doing absolutely nothing for 15 seconds while it waits for the AI to respond. If you have 5 users asking for summaries at the same time, your entire server will lock up. No one else will be able to load your website. The browser might even time out and show an error page.

AI calls are slow. You must put them in the background.

In 2026, Rails 8 makes this ridiculously easy because we have Solid Queue built-in. We don't need to install Redis. We just use our existing PostgreSQL database. Here is how to move your AI calls to the background and use Hotwire to update the user's screen in real-time.

STEP 1: The Empty State View

When a user clicks "Generate Summary", we want the page to load instantly. We will show them a loading spinner while the AI thinks in the background.

To do this, we need to set up a Hotwire listener (turbo_stream_from) on our document page.

<!-- app/views/documents/show.html.erb -->
<h1><%= @document.title %></h1>

<!-- 1. Listen for WebSocket broadcasts attached to this specific document -->
<%= turbo_stream_from @document %>

<!-- 2. The target div that we will update later -->
<div id="<%= dom_id(@document, :summary) %>">

  <% if @document.summary.present? %>
    <p><%= @document.summary %></p>
  <% else %>
    <p class="text-gray-500 animate-pulse">🤖 AI is generating your summary...</p>
  <% end %>

</div>

STEP 2: The Fast Controller

Now, we update our controller. Instead of calling the AI, we just tell our background queue to handle it, and we immediately render the page.

# app/controllers/summaries_controller.rb
class SummariesController < ApplicationController
  def create
    @document = Document.find(params[:document_id])

    # Send the heavy lifting to Solid Queue!
    GenerateSummaryJob.perform_later(@document.id)

    # Instantly redirect back to the show page
    redirect_to @document, notice: "Summary is generating..."
  end
end

Your controller now executes in 0.02 seconds instead of 15 seconds. Your server is happy.

STEP 3: The Solid Queue Job

Now we create the actual job that will run in the background.

rails generate job generate_summary

Inside this job, we make the slow API call, save the result to the database, and then broadcast the new HTML over WebSockets so the user's screen updates without them refreshing the page.

# app/jobs/generate_summary_job.rb
class GenerateSummaryJob < ApplicationJob
  queue_as :default

  def perform(document_id)
    document = Document.find(document_id)

    # 1. The Slow API Call (Takes 10-15 seconds)
    client = OpenAI::Client.new(access_token: ENV['OPENAI_ACCESS_TOKEN'])
    response = client.chat(
      parameters: {
        model: "gpt-4o",
        messages:[{ role: "user", content: "Summarize this: #{document.text}" }]
      }
    )

    summary_text = response.dig("choices", 0, "message", "content")

    # 2. Save to database
    document.update!(summary: summary_text)

    # 3. The Hotwire Magic: Broadcast the new HTML to the user!
    Turbo::StreamsChannel.broadcast_replace_to(
      document, # Matches the turbo_stream_from in our view
      target: "document_#{document.id}_summary", # The ID of the div to replace
      partial: "documents/summary", # A partial containing the final text
      locals: { document: document }
    )
  end
end

STEP 4: The Broadcast Partial

In the job above, we told Hotwire to render a partial called documents/summary. Let's create that tiny file so Hotwire knows what HTML to send over the WebSocket.

<!-- app/views/documents/_summary.html.erb -->
<div id="<%= dom_id(document, :summary) %>">
  <div class="p-4 bg-green-50 border border-green-200 rounded-lg">
    <h3 class="font-bold text-green-800">AI Summary Complete:</h3>
    <p><%= document.summary %></p>
  </div>
</div>

Summary

This is the ultimate workflow for the modern AI application. Look at what we achieved without writing a single line of custom JavaScript:

User Experience: The user clicks a button and gets instant feedback (the loading state). They don't stare at a frozen browser.
Server Health: The Puma web server is free to handle hundreds of other users because the 15-second AI wait time is offloaded to a background worker.
Simplicity: Because of Rails 8 and Solid Queue, we don't have to manage Redis servers or complex infrastructure. The jobs live right in our standard database.
Real-Time UI: Hotwire securely pushes the finished HTML directly into the user's browser the exact millisecond the AI finishes thinking.

If you are building AI wrappers, this exact pattern is your blueprint for success.

Forem: Zil Norvilis

n8n vs ByteChef: Which Automation Engine Should You Self-Host?

1. n8n: The Versatile Giant

2. ByteChef: The Structured Alternative

Side-by-Side Comparison

Why I’m Sticking with n8n (For Now)

Summary

Distributed Uniqueness: Implementing Twitter Snowflake IDs in Rails 8

What is a Snowflake ID?

STEP 1: The Ruby Implementation

STEP 2: Making it the Primary Key in Rails

STEP 3: The Migration

Why this is a Win for Solo Devs

1. Cleaner URLs

2. Native Performance

3. Frontend Friendly

Summary

The Vibe Coder’s Survival Guide: Concepts You Can’t Just Prompt Away

LEVEL 1: State (The Memory)

LEVEL 2: Control Flow (The Path)

LEVEL 3: The Request/Response Cycle (The Mailman)

LEVEL 4: Data Shapes (Arrays and Hashes)

LEVEL 5: Persistence (The Database)

Summary: The Hybrid Workflow

The Perfect Zsh Setup: Oh My Zsh on CachyOS/Arch

1. Install the Foundations

2. Install Oh My Zsh

3. The "Master" Configuration (.zshrc)

4. Final Polish (Icons & Colors)

Fix the Icons

Apply Changes

Why this setup is better:

✅ Green/Red Syntax

✅ Inline Ghost Suggestions

✅ Smart Git Branches

✅ rbenv Integration

Pro-Tip for CachyOS Users:

Completing the Puzzle: Adding Signup and Password Resets to Rails 8 Auth

Phase 1: The Signup Flow (Registrations)

STEP 1: The Controller

STEP 2: The Routes and View

Phase 2: Password Resets (The Modern Way)

STEP 1: Update the User Model

STEP 2: The Passwords Controller

STEP 3: The Mailer

STEP 4: The Routes

Why this is better than a Gem

Summary

Rails 8 Built-in Auth vs. Devise: Why the Default Finally Wins

1. Ownership vs. Magic

2. No More "Gem Bloat"

3. Rate Limiting is Built-In

4. Easy to Upgrade to Passkeys

Summary: Which one should you pick?

Build Once, Launch Ten Times: The Rails Engine SaaS Strategy

What is a Rails Engine?

STEP 1: Generate the Engine

STEP 2: Add the "Boring" SaaS Logic

STEP 3: Shared UI (The Design System)

STEP 4: The Local Development Workflow

Why this is the ultimate Solopreneur hack

1. The "Bug Once, Fix Everywhere" Rule

2. Zero-Friction Launching

3. Ownership

Summary

Ditching Redis: How to Handle WebSockets in Rails 8 with Solid Cable

Real-Time Rails Without Redis: A Guide to Solid Cable

The Mental Model: How can a Database handle WebSockets?

STEP 1: Installation and Database Setup

STEP 2: The Configuration (cable.yml)

STEP 3: Using It (The Code Stays the Same!)

Summary

The Magic of Turbo Frames: Infinite Pagination in Pure HTML

Building an Infinite Scroll in Rails 8 (Zero Custom JavaScript)

The Strategy

STEP 1: The Controller

STEP 2: The View (The Magic Frame)

How It Actually Works (Step-by-Step)

STEP 3: Optimization (The Pro Move)

Summary

3. The "Master" Configuration (`.zshrc`)

STEP 2: The Configuration (`cable.yml`)