Forem: Zil Norvilis

Build Your Own Cloud Empire: Hosting Unlimited Rails Apps with Kamal 2

Zil Norvilis — Tue, 05 May 2026 23:23:47 +0000

If you are a solo developer or an indie hacker, you probably suffer from "Shiny Object Syndrome." You have 10 different ideas, and you want to launch all of them.

In the old days, launching an MVP was expensive. You used Heroku or Render. You paid $7 for the web server, $9 for the database, and $5 for Redis. That is $21 per app. If you have 5 side projects, you are paying over $100 a month just to host apps that might have zero active users.

This "PaaS Tax" kills innovation. It makes you afraid to launch new things.

But in 2026, with the release of Kamal 2, you don't need a Platform-as-a-Service anymore. You can rent raw, cheap Linux servers and build your own "Cloud Empire." You can host 10 different Rails apps on the exact same server, completely isolated from each other, for a fixed price of $10 a month.

Here is the step-by-step guide to building your own multi-app VPS cluster using Kamal 2.

The Strategy: The Kamal Proxy

Before we start, you need to understand how this is possible.

Normally, only one application can listen to Port 80 (HTTP) and Port 443 (HTTPS) on a server. If App A is using it, App B will crash.

Kamal 2 solves this with Kamal Proxy. When you deploy your first app, Kamal silently installs a master proxy at the front door of your server. This proxy listens to the internet. When a request comes in, the proxy looks at the domain name (app1.com vs app2.com) and routes the traffic to the correct Docker container.

It handles the SSL certificates (HTTPS) automatically. It handles zero-downtime deployments. And it allows infinite apps to share one server.

STEP 1: The Base Hardware

First off, go to a cloud provider like Hetzner, DigitalOcean, or Linode.
Rent a cheap Ubuntu VPS. A $10/month server on Hetzner gives you an ARM processor with 4 vCPUs and 8GB of RAM.

Because Rails 8 is so efficient (especially if you use SQLite for your MVPs), 8GB of RAM is enough to comfortably run 10 to 15 separate Rails applications.

Write down the IP address of your new server.

STEP 2: Deploying App Number 1

Let's deploy your first idea: project-alpha.com.

In your first Rails application, open config/deploy.yml. You configure it to point to your new server IP, and you tell Kamal Proxy which domain belongs to this app.

# project_alpha/config/deploy.yml
service: project-alpha
image: your_docker_username/project-alpha

servers:
  web:
    - 192.168.1.100 # Your Server IP

proxy:
  ssl: true
  host: project-alpha.com

registry:
  # ... your docker registry credentials

In your terminal, run:

kamal setup

Kamal will SSH into your server, install Docker, install Kamal Proxy, issue an SSL certificate, and start project-alpha.

STEP 3: Deploying App Number 2 (Sharing the Server)

Now you have a second idea: project-beta.com.

You do not need to buy a second server. You just point your DNS records for project-beta.com to the exact same IP address (192.168.1.100).

Open the deploy.yml for your second Rails app:

# project_beta/config/deploy.yml
service: project-beta
image: your_docker_username/project-beta

servers:
  web:
    - 192.168.1.100 # The EXACT SAME IP

proxy:
  ssl: true
  host: project-beta.com

Run kamal setup in this second app.

Kamal is smart enough to realize that Docker and Kamal Proxy are already installed on that server. It skips the heavy setup, deploys the new project-beta container alongside the first one, and registers the new domain name with the proxy.

Boom. Two apps, one server, one $10 bill.

STEP 4: Scaling the Empire (The Database Node)

Hosting 10 apps with SQLite on one server is great for MVPs. But what happens when project-alpha goes viral and gets thousands of users? It starts eating all the CPU, slowing down your other 9 apps.

It is time to turn your single server into a Cluster.

You rent a second $10 VPS. This will be your Database Server.
Instead of spinning up managed RDS databases on AWS for $50/month, you use Kamal's "Accessories" feature to install a massive PostgreSQL container on this new server.

In your project-alpha deploy file, you separate your architecture:

# project_alpha/config/deploy.yml
service: project-alpha

# The Web server stays on Node 1
servers:
  web:
    - 192.168.1.100 

# The Database moves to Node 2
accessories:
  db:
    image: postgres:15
    host: 192.168.1.200 # Your NEW Server IP
    port: 5432
    env:
      clear:
        POSTGRES_DB: project_alpha_prod
        POSTGRES_USER: admin
      secret:
        - POSTGRES_PASSWORD
    files:
      - db_data:/var/lib/postgresql/data

Now, your web traffic hits Server 1, and your database queries route securely to Server 2. You have built a distributed cloud architecture without writing a single line of Kubernetes configuration.

Summary

The "One Person Framework" doesn't just apply to writing code. It applies to infrastructure.

With Kamal 2, you have total control.

You can launch unlimited MVPs on a single cheap server.
The proxy handles routing and SSL automatically.
When an app gets traction, you just add another server IP to your deploy.yml and scale horizontally.

You are no longer renting a tiny slice of a PaaS. You own the hardware. Go build your empire.

Images, Volumes, and Containers: Docker Explained in Plain English

Zil Norvilis — Mon, 04 May 2026 23:23:45 +0000

Very often I see developers completely give up on learning Docker because of the vocabulary.

You read a tutorial and the author says: "Just build the Dockerfile into an Image, mount the Volume, map the Ports, and spin up the Container." If you don't have a DevOps background, that sounds like alien gibberish.

The truth is, Docker is incredibly simple. It is just a virtual "shipping box" for your code. But because the creators of Docker invented their own terminology, it feels intimidating.

If you want to deploy modern web apps (especially using tools like Kamal 2), you need to know what these words actually mean. Here is the absolute simplest translation of Docker jargon into plain English.

1. The Dockerfile (The Recipe)

Imagine you are opening a bakery. The Dockerfile is your master recipe book.

It is literally just a plain text file. It contains a list of instructions on exactly how to build your application's environment from a completely blank slate.

It says:

Buy an oven (Install Linux).
Buy some flour (Install Ruby/Node.js).
Bring in the secret ingredients (Copy your app's code).
Mix it all together (Run bundle install or npm install).

A Dockerfile doesn't do anything on its own. It is just a piece of paper waiting to be read.

2. The Image (The Frozen Cake)

When you run the command docker build, Docker reads your recipe (the Dockerfile) and goes to work.

When it finishes all the steps, it takes a massive, frozen snapshot of the entire system. This snapshot is called an Image.

An Image is read-only. You cannot change the code inside an Image once it is built.
It is heavy. It might be 500MB or 1GB because it contains a whole mini-operating system.
Think of the Image as the CD-ROM of a video game. The CD holds all the game files, but the CD itself doesn't "play" the game until you put it in a console.

3. The Container (The Running Machine)

This is the word people get confused by the most.

If the Image is the CD-ROM, the Container is the game actually running on your TV.

When you run the command docker run, Docker takes your frozen Image, wakes it up, gives it some RAM and CPU power, and turns it into a living, breathing Container.

You can run 10 Containers from 1 Image. (Just like you can install the same CD-ROM onto 10 different computers).
Containers are completely isolated from your actual laptop. They think they are the only thing existing in the universe.

4. Volumes (The USB Flash Drive)

Here is the most dangerous thing about Containers: They have amnesia.

If your Container is running your database (like PostgreSQL or SQLite), and you restart the Container or it crashes, all your data is permanently deleted. A Container always wakes up looking exactly like the original, frozen Image.

To solve this, we use Volumes.

A Volume is like a USB Flash Drive that you plug into the side of the Container. You tell Docker: "Hey, whenever the database saves a file, don't save it inside the Container's memory. Save it onto this USB drive."

This way, if the Container explodes and dies, your data is safe on the Volume. When you boot up a brand new Container tomorrow, you just plug that same Volume back in, and your database is exactly where you left off.

5. Ports (The Doors)

As I mentioned earlier, Containers are isolated. They are like locked bank vaults.

If you have a Rails or Node app running on port 3000 inside the Container, and you open your browser to http://localhost:3000 on your Mac, it won't work. Your Mac cannot see inside the vault.

You have to punch a hole in the wall. This is called Port Mapping.

When you start the container, you pass a flag like -p 8080:3000. This tells Docker:
"If anyone knocks on door 8080 of my actual laptop, open a secret tunnel and send them to door 3000 inside the Container."

6. The Registry (The App Store)

Finally, how do you get your Image from your laptop to your production server? You use a Registry.

A Registry is just Dropbox for Docker Images. The most famous one is Docker Hub, but GitHub has one too (GHCR).

The workflow is simple:

You build the Image on your laptop.
You docker push the Image up to the Registry.
You log into your cheap $5 cloud server.
You docker pull the Image down from the Registry.
You run it.

(Side note: This exact 5-step process is what deployment tools like **Kamal* do automatically for you!)*

Summary

Don't let the DevOps gatekeepers confuse you. The mental model is actually very logical:

Dockerfile: The blueprint.
Image: The frozen snapshot built from the blueprint.
Container: The running instance of the snapshot.
Volume: The external hard drive to save your data.
Ports: The tunnels to let internet traffic inside.
Registry: The cloud storage to hold your snapshots.

Once these terms click in your brain, Docker stops being a scary black box and becomes the most reliable tool in your entire development stack.

How to Build a Desktop App with Rails 8 and Electron

Zil Norvilis — Sat, 02 May 2026 23:23:47 +0000

From Web to Desktop: Wrapping a Rails Hotwire App in Electron

Very often I find myself building a successful web application, and inevitably, a user asks the golden question: "Do you have a desktop app for Mac or Windows?"

As a solo developer, hearing this used to give me anxiety. I am a Ruby developer. I don't have the time to learn Swift for macOS, C# for Windows, or rewrite my entire frontend in React just to use a desktop framework.

But in 2026, you don't have to. You can take your existing Rails app, wrap it in Electron, and ship it as a native desktop application.

The secret reason this works so well today is Hotwire. Because Turbo intercepts link clicks and updates the page without doing a full browser reload, your web app inside Electron doesn't have that ugly "white flash" between pages. It actually feels like a native desktop app.

Here is how to wrap your Rails app into an Electron desktop app in 4 easy steps.

STEP 1: The Electron Setup

Since Electron runs on Node.js, we do need to step out of the Ruby world just for a minute to create our desktop "shell".

Create a new folder completely separate from your Rails app, and initialize a basic Node project:

mkdir my-desktop-app
cd my-desktop-app
npm init -y
npm install electron --save-dev

In your package.json, update the main entry point and add a start script:

{
  "name": "my-desktop-app",
  "version": "1.0.0",
  "main": "main.js",
  "scripts": {
    "start": "electron ."
  }
}

STEP 2: The Main Process (Loading Rails)

Now we create the main.js file. This is the brain of your desktop app. Its entire job is to boot up a chromium window and point it to your Rails server.

Create main.js:

const { app, BrowserWindow, shell } = require('electron')
const path = require('path')

function createWindow () {
  const win = new BrowserWindow({
    width: 1200,
    height: 800,
    titleBarStyle: 'hiddenInset', // Makes it look modern on Mac
    webPreferences: {
      preload: path.join(__dirname, 'preload.js'),
      nodeIntegration: false,
      contextIsolation: true
    }
  })

  // In development, point to localhost. 
  // In production, point to your real HTTPS domain.
  win.loadURL('http://localhost:3000')

  // STEP 3 LOGIC GOES HERE...
}

app.whenReady().then(() => {
  createWindow()
})

If you run npm start right now (while your Rails server is running on port 3000), a beautiful desktop window will open, displaying your Rails app!

STEP 3: Handling External Links

There is one immediate problem. If a user clicks a link in your app that goes to https://twitter.com, Twitter will load inside your Electron app. You don't want that. You want external links to open in the user's default browser (like Chrome or Safari).

We can intercept these links inside main.js. Add this inside your createWindow function:

  // Intercept links opening in new windows
  win.webContents.setWindowOpenHandler(({ url }) => {
    // If the URL is not your Rails app, open it in the default browser
    if (!url.includes('localhost:3000')) {
      shell.openExternal(url)
      return { action: 'deny' }
    }
    return { action: 'allow' }
  })

Note: In Rails, make sure your external links have target="_blank" so Electron knows it is trying to open a new window!

STEP 4: The Hotwire Bridge (Stimulus)

Your app looks great, but what if you want to use Native Desktop features? What if you want to trigger a native Desktop Notification when a Rails background job finishes?

We need our Rails app to "talk" to Electron. We do this using a preload.js file.

Create preload.js in your Electron folder:

const { contextBridge, ipcRenderer } = require('electron')

// We expose a safe API to the browser window
contextBridge.exposeInMainWorld('desktopAPI', {
  sendNotification: (title, body) => {
    // We send a message to the Electron main process
    new Notification(title, { body: body })
  }
})

Now, back in your Rails App, you can write a simple Stimulus controller to trigger this!

rails g stimulus desktop

// app/javascript/controllers/desktop_controller.js
import { Controller } from "@hotwired/stimulus"

export default class extends Controller {
  notify() {
    // We check if 'window.desktopAPI' exists. 
    // If they are using a normal web browser, it will be undefined.
    // If they are in our Electron app, it will run!
    if (window.desktopAPI) {
      window.desktopAPI.sendNotification("Task Complete", "Your export is ready.")
    } else {
      alert("Task Complete (Web Version)")
    }
  }
}

Attach this controller to a button in your Rails view: <button data-controller="desktop" data-action="click->desktop#notify">Test Notification</button>.

Summary

The "Write Once, Run Anywhere" dream used to be a myth. But the modern Rails stack makes it incredibly close to reality.

Your Rails backend handles the database and logic.
Hotwire makes the frontend feel instant and native.
Hotwire Native wraps it for iOS and Android.
Electron wraps it for macOS and Windows.

By simply pointing an Electron window at your Rails URL and exposing a few features via a Stimulus bridge, you can offer your users a premium desktop experience without maintaining a separate codebase.

High ROI Testing: The 3 Secrets Every Solo Rails Dev Needs

Zil Norvilis — Fri, 01 May 2026 23:11:26 +0000

Very often I see solo developers fall into one of two traps.

Trap number one: They read a book on Enterprise Test-Driven Development (TDD) and spend 3 weeks writing unit tests for a product that has zero users. They burn out and quit.

Trap number two: They write zero tests because they want to "move fast." Then, their app gets its first 100 users, and they become completely paralyzed. They are terrified to push a new feature on a Friday because they don't know if they will break the checkout page.

When you are a "One-Person Team," your scarcest resource is time. You cannot test everything. You need to focus on High ROI (Return on Investment) Testing. You need the absolute maximum amount of confidence with the minimum amount of code.

Here are my top 3 tips for testing as a solo developer to keep your momentum high and your anxiety low.

TIP 1: System Tests > Unit Tests

If you only have time to write one type of test, ignore the models and ignore the controllers. Write System Tests.

A system test boots up a real browser in the background, goes to your URL, and clicks buttons just like a human user would.

Why is this so powerful? Because a single system test verifies your routing, your controller logic, your database queries, and your HTML rendering all at once. If you rewrite your entire backend logic, your system test doesn't care. It just cares that the user can still click the button.

Focus on testing the "Golden Paths" - the actions that actually make you money.

# test/system/checkout_test.rb
require "application_system_test_case"

class CheckoutTest < ApplicationSystemTestCase
  test "user can sign up and pay for a subscription" do
    visit pricing_path
    click_on "Buy Pro"

    fill_in "Email", with: "customer@example.com"
    fill_in "Password", with: "secret123"
    click_on "Sign Up"

    assert_text "Welcome to Pro!"
    assert User.last.pro_plan?
  end
end

TIP 2: Embrace Rails Fixtures (Ditch FactoryBot)

The Ruby community loves FactoryBot. Factories are incredibly flexible, but they have a massive hidden cost: Speed.

Factories dynamically generate and insert records into your database on every single test run. If you have a complex app, running 50 tests can suddenly take 30 seconds. If your tests are slow, you will stop running them.

As a solo dev, you should use the Rails default: Fixtures.

Fixtures are simple YAML files that get loaded directly into your test database exactly once when the test suite boots.

# test/fixtures/users.yml
zil:
  email: zil@example.com
  encrypted_password: <%= User.new.send(:password_digest, 'password') %>
  status: active

Because the data is already in the database before the test even starts, a Minitest suite using fixtures runs in a fraction of a second. Fast tests mean you will actually use them while you code.

TIP 3: Never Hit Real APIs (Use VCR)

If your app talks to Stripe, OpenAI, or a weather API, do not let your test suite make real network requests.

It slows your tests down to a crawl.
It makes your tests flaky (if the API is down, your test fails).
You might accidentally hit a rate limit and get banned.

Instead, use a gem called VCR.

VCR intercepts the HTTP request the very first time you run the test, saves the API's response to a local text file (a "cassette"), and then replays that text file instantly on all future test runs.

class OpenAiServiceTest < ActiveSupport::TestCase
  test "generates a summary from the API" do
    # VCR intercepts the network call perfectly
    VCR.use_cassette("openai_summary") do
      summary = OpenAiService.summarize("Long text here...")
      assert_match /Expected output/, summary
    end
  end
end

Your tests run offline, instantly, and with 100% predictable results.

💡 Shameless Plug: Want to master this workflow?
If you are tired of guessing what to test, fighting with flaky setups, or feeling anxious every time you deploy, I’ve packaged my entire exact testing strategy into a comprehensive guide.

Check out Wise Testing: The Solo Developer's Guide to Rails Testing. You will learn how to set up lightning-fast Minitest suites, test complex Webhooks, and build a safety net that protects your startup without slowing you down.

Summary

Testing doesn't have to be a chore that steals time away from building features. If you approach it pragmatically:

Test the user experience (System Tests).
Optimize for speed (Fixtures).
Isolate the network (VCR).

You will end up with a safety net that lets you code fearlessly and deploy on Fridays.

The Importmap Guide to Shadcn: Beautiful UI with Zero Build Step

Zil Norvilis — Thu, 30 Apr 2026 23:11:28 +0000

How to Use Shadcn UI in Rails 8 (Without React or Webpack)

If you have looked at frontend design anytime recently, you have definitely seen shadcn/ui. It is the most popular UI library in the world right now. It looks beautiful, minimal, and highly professional.

Very often I find myself wanting to use these beautiful components in my Rails apps. But immediately, I hit a massive wall.

Shadcn is built strictly for React. Its installation instructions ask you to run npx, install a bunch of Node.js dependencies, and compile JSX code.

If you are using Rails 8 with Importmaps, you do not have a build step. You do not have Node.js. You cannot just run bin/importmap pin shadcn because browsers do not understand React JSX natively.

Does this mean we can't use it? No.
Shadcn is just a combination of two things: Tailwind CSS (for the design) and Radix UI (for the JavaScript behavior). We can easily replicate this in pure Rails using Importmaps and Stimulus.

Here is exactly how to get the Shadcn experience in a modern Rails 8 app.

STEP 1: The Reality Check (What are we actually doing?)

Because we are not using React, we are going to do what I call "Design Extraction."

We are going to steal the beautiful HTML and Tailwind classes from Shadcn, and we are going to replace the heavy React JavaScript with lightweight Stimulus controllers.

To do this, your Rails 8 app needs to have Tailwind CSS installed. If you generated your app with Tailwind, you are ready to go. If not, you can add it easily:

bundle add tailwindcss-rails
rails tailwindcss:install

STEP 2: Pin the Stimulus Helpers (Importmap)

Shadcn components like Modals, Dropdowns, and Tabs need JavaScript to open and close. We don't want to write this Javascript from scratch.

Instead, we will use an amazing open-source library called tailwindcss-stimulus-components. It provides pre-written Stimulus controllers that do exactly what Shadcn's React code does (toggling classes, handling clicks, managing focus).

Since we are using Importmaps, we install it straight from the terminal:

bin/importmap pin tailwindcss-stimulus-components

Now, we need to register these controllers in our Javascript file.

// app/javascript/controllers/index.js
import { application } from "controllers/application"
import { Dropdown, Modal, Tabs, Popover } from "tailwindcss-stimulus-components"

application.register('dropdown', Dropdown)
application.register('modal', Modal)
application.register('tabs', Tabs)
application.register('popover', Popover)

STEP 3: Stealing the Shadcn Design

Let's build a Shadcn-style Dropdown Menu.

If you go to the Shadcn documentation, you will see a beautiful React component. We ignore the React code. We just look at the design: white background, subtle border, small shadows, and rounded corners.

We write plain HTML, apply those exact Tailwind classes, and wrap it in our new Stimulus dropdown controller:

<!-- A Shadcn-style Dropdown in pure Rails -->
<div data-controller="dropdown" class="relative inline-block text-left">

  <!-- The Trigger Button -->
  <button data-action="click->dropdown#toggle click@window->dropdown#hide" 
          class="inline-flex items-center justify-center rounded-md text-sm font-medium border border-gray-200 bg-white px-4 py-2 hover:bg-gray-100 hover:text-gray-900 transition-colors">
    Open Menu
  </button>

  <!-- The Dropdown Content (Hidden by default) -->
  <div data-dropdown-target="menu" 
       class="hidden absolute right-0 mt-2 w-56 rounded-md border border-gray-200 bg-white shadow-md p-1 z-50 transition transform origin-top-right">

    <a href="#" class="block px-2 py-1.5 text-sm text-gray-700 hover:bg-gray-100 hover:text-gray-900 rounded-sm">
      Profile
    </a>
    <a href="#" class="block px-2 py-1.5 text-sm text-gray-700 hover:bg-gray-100 hover:text-gray-900 rounded-sm">
      Settings
    </a>

    <div class="h-px bg-gray-200 my-1"></div> <!-- Divider -->

    <%= button_to "Log out", destroy_user_session_path, method: :delete, 
        class: "w-full text-left px-2 py-1.5 text-sm text-red-600 hover:bg-gray-100 rounded-sm" %>
  </div>
</div>

Why this works:

The CSS gives it the exact premium, crisp look of Shadcn.
The data-controller="dropdown" uses the Stimulus library we pinned via Importmap to handle the open/close logic and clicking outside the menu.
We didn't write a single line of custom Javascript or touch Webpack.

STEP 4: Creating Reusable Components (The Rails Way)

The magic of Shadcn in React is that you just write <Button>Click me</Button>.

If you copy-paste the massive Tailwind HTML above every time you need a dropdown, your views will become a nightmare. In Rails, we solve this by wrapping our new designs into Rails Helpers or ViewComponents.

Let's turn the famous Shadcn Button into a simple Rails helper.

# app/helpers/ui_helper.rb
module UiHelper
  def shadcn_button(text, path, style: :primary, **options)
    base_classes = "inline-flex items-center justify-center rounded-md text-sm font-medium transition-colors focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 px-4 py-2"

    style_classes = case style
    when :primary
      "bg-slate-900 text-white hover:bg-slate-900/90"
    when :secondary
      "bg-slate-100 text-slate-900 hover:bg-slate-100/80"
    when :destructive
      "bg-red-500 text-white hover:bg-red-500/90"
    when :outline
      "border border-slate-200 bg-white hover:bg-slate-100 hover:text-slate-900"
    else
      ""
    end

    css_classes = "#{base_classes} #{style_classes} #{options[:class]}"

    link_to text, path, class: css_classes, **options.except(:class)
  end
end

Now, anywhere in your app, you can just write:

<%= shadcn_button "Save Changes", save_path, style: :primary %>
<%= shadcn_button "Delete", delete_path, style: :destructive %>

Summary

Don't let the React community trick you into thinking you need a massive Javascript build step just to have beautiful buttons and modals.

Shadcn is just a design system. It is Tailwind CSS.
React is just the engine. We replace it with Stimulus via Importmaps.
Components are just helpers. We replace JSX with Rails Helpers or ViewComponents.

By combining tailwindcss-stimulus-components and some smart Rails helpers, you can get 100% of the visual beauty of Shadcn while keeping the blazing fast, no-build-step architecture of Rails 8.

The Secret to Side-by-Side Gem Development in Rails

Zil Norvilis — Wed, 29 Apr 2026 23:10:27 +0000

Stop Pushing to GitHub: How to Test Ruby Gems Locally

Very often I find myself writing a piece of code in a Rails app and thinking: "I use this in all my projects. I should extract this into a Ruby Gem."

Building a gem is a great way to clean up your codebase and contribute to open-source. But the first time you try to build one, the testing process feels awful.

Most beginners write some code in their gem, push it to GitHub, go to their Rails app, run bundle update my_gem, restart the server, and see if it worked. If there is a typo, they have to do the whole 5-minute loop all over again.

You do not need to do this. You can develop your gem and your Rails app side-by-side on your local machine, and see your changes instantly. Here is exactly how to set it up.

STEP 1: The Folder Structure

To keep things organized, both your gem and your Rails app should live in the same parent directory on your computer.

Open your terminal and create a new gem using Bundler's built-in generator:

bundle gem awesome_tool

This creates a folder called awesome_tool with all the boilerplate code you need for a gem. Next, go back to the parent folder and create a dummy Rails app to test it on:

rails new test_app

Now your folder structure looks like this:

~/projects/awesome_tool (Your Gem)
~/projects/test_app (Your Rails App)

STEP 2: The Magic Link (`path`)

Now we need to tell our Rails app to use the local folder instead of downloading the gem from the internet.

Open the Gemfile inside your test_app and add this line:

# test_app/Gemfile

gem 'awesome_tool', path: '../awesome_tool'

The path: option is the secret sauce. It tells Bundler to look in the neighboring folder on your hard drive.

Run bundle install in your Rails app. You will see Bundler confirm that it is using the local source.

STEP 3: Write Code in the Gem

Let's add a simple feature to our gem to make sure they are connected.

Open the main file inside your gem directory (awesome_tool/lib/awesome_tool.rb) and write a simple method:

# awesome_tool/lib/awesome_tool.rb
require_relative "awesome_tool/version"

module AwesomeTool
  def self.say_hello
    "Hello from the local gem!"
  end
end

STEP 4: Test it in Rails

Go back to your test_app terminal and open the Rails console:

rails console

Type AwesomeTool.say_hello. It will output "Hello from the local gem!".

If you go back to your gem, change the text to "Wow, this is fast!", and then restart your Rails console, the new text will be there instantly. No Git commits, no pushing to the internet.

STEP 5: The Pro Move (`bundle config`)

The path: trick is perfect when you are building a brand new gem from scratch.

But what if you are contributing to a huge open-source gem (like devise or sidekiq)? You want to test your bug fix on your company's real Rails app.
However, you cannot change the Gemfile to path: '../devise', because if you accidentally commit that Gemfile to GitHub, you will break the app for all your coworkers!

For this, we use the bundle config local trick.

Leave your Rails Gemfile pointing to GitHub normally:

# Gemfile
gem 'sidekiq', github: 'sidekiq/sidekiq'

Then, in your terminal, tell Bundler to override that specific gem locally on your computer:

bundle config local.sidekiq /Users/yourname/projects/sidekiq

Now, every time you run your Rails app, it will silently use your local folder instead of GitHub. Your Gemfile stays perfectly clean, so you can never accidentally commit a broken path to production.

To turn this off when you are done testing, just run:

bundle config --delete local.sidekiq

Summary

Building gems doesn't have to be a slow, frustrating process.

Use gem 'name', path: '../name' for quick, brand new gems you are building yourself.
Use bundle config local.name /path when testing changes to established gems without messing up your team's Gemfile.

Extracting your complex logic into local gems is a fantastic way to clean up a messy Rails monolith, and this workflow makes it completely painless.

The Language of the Web: HTTP Basics You Actually Need to Know

Zil Norvilis — Tue, 28 Apr 2026 23:11:32 +0000

HTTP Basics You Must Know As A Web Developer

Very often I see new developers build an entire web application using Rails, React, or Laravel. They know how to write database queries and build components. But the moment they try to connect to a third-party API and get a weird "401 Unauthorized" or "CORS" error, they completely freeze.

The problem is that modern frameworks are almost too good. They hide the raw communication of the internet behind "magic" methods.

Underneath all the Ruby, PHP, and JavaScript, the internet runs on a very simple text-based language called HTTP (Hypertext Transfer Protocol). If you don't understand how HTTP works, debugging web apps is incredibly painful.

Here are the 5 core concepts of HTTP that you absolutely must know to be a confident web developer.

CONCEPT 1: The Request and Response Cycle

HTTP is just a conversation between two computers: the Client (your browser or mobile app) and the Server (your Rails/Node app).

The conversation is strictly turn-based.

The Client asks a question (The Request).
The Server gives an answer (The Response).

The server will never speak to the client unless the client speaks first. (This is why WebSockets were invented later, to allow two-way chatting, but standard HTTP is always a 1-way ask-and-receive).

If you strip away your framework, a raw HTTP Request literally just looks like this simple text:

GET /users HTTP/1.1
Host: api.myapp.com
Accept: application/json

And the Server's Response looks like this:

HTTP/1.1 200 OK
Content-Type: application/json

{ "name": "Zil", "role": "admin" }

CONCEPT 2: The Verbs (Methods)

When the Client sends a request, it has to tell the Server what action it wants to perform. We use "Verbs" for this.

If you know database CRUD (Create, Read, Update, Delete), these map perfectly to HTTP verbs.

GET (Read): "Give me some data." (e.g., loading a webpage or fetching a user profile). GET requests should never change the database.
POST (Create): "Here is some new data, save it." (e.g., submitting a sign-up form).
PUT / PATCH (Update): "Here is some updated data, change an existing record." (PATCH is for partial updates, PUT usually replaces the whole record).
DELETE (Destroy): "Delete this record."

Rookie Mistake: Never use a GET request to delete a user (like /users/delete/1). If Google's web crawler bots find that link, they will visit it and accidentally delete your users! Always use the correct verb.

CONCEPT 3: Status Codes (The 5 Buckets)

When the Server responds, it gives a 3-digit number called a Status Code. You don't need to memorize all 60 of them. You just need to know the 5 main buckets.

1xx (Informational): "Hang on, I'm thinking." (You rarely see these).
2xx (Success): "Everything went perfectly!"
- 200 OK: Standard success.
- 201 Created: Successfully saved a new record.
3xx (Redirection): "The thing you want is over there."
- 301/302: Redirecting the user to a new URL.
4xx (Client Error): "YOU messed up."
- 400 Bad Request: You sent missing or invalid data.
- 401 Unauthorized: You forgot your API key or aren't logged in.
- 403 Forbidden: You are logged in, but you don't have admin rights to see this.
- 404 Not Found: You asked for a URL that doesn't exist.
5xx (Server Error): "I (the server) messed up."
- 500 Internal Server Error: Your backend code crashed. Check your server logs!

CONCEPT 4: Headers (The Hidden Metadata)

Both the Request and the Response have "Headers". Headers are just key-value pairs of hidden information. They are the metadata of the conversation.

As a developer, you will deal with two headers constantly:

1. Content-Type:
This tells the other computer what kind of data is in the body of the message.
If your Rails API sends JSON, but forgets to set Content-Type: application/json, the frontend Javascript might think it's just raw text and crash when trying to parse it.

2. Authorization:
This is how APIs handle security. Instead of sending a username and password every time, you usually pass a token in the headers.

Authorization: Bearer my_secret_api_key_123

CONCEPT 5: Statelessness (The Goldfish Memory)

This is the most important concept to grasp. HTTP is completely stateless.

HTTP has the memory of a goldfish. If you send a request to a server, and then send a second request 1 millisecond later, the server has absolutely no idea that you are the same person. It treats every single request as a brand new stranger.

So, how does a website keep you "logged in"?
Cookies.

When you log in successfully (POST request), the Server's response includes a special header: Set-Cookie: session_id=abc123.
Your browser saves that cookie. On your next request, your browser automatically attaches that cookie in the headers. The server reads the cookie and says, "Ah, I remember this session ID, you are logged in."

Summary

When an API integration breaks, don't just stare at your Ruby or Javascript code. Look at the raw HTTP request in your browser's Network tab.

Did you use the right Verb? (POST instead of GET?)
What was the Status Code? (401 means check your auth token, 500 means check your server logs).
Are your Headers correct? (Is Content-Type set to JSON?)

Once you understand that HTTP is just simple text being passed back and forth, web development becomes a lot less scary and a lot more logical.

Stop Using Ugly Browser Alerts: Custom Turbo Confirms in Rails 8

Zil Norvilis — Mon, 27 Apr 2026 23:11:26 +0000

I'm building a really nice, modern Rails application. I use Tailwind to make the buttons look great, I use Hotwire to make the page load instantly, and then... I click a "Delete" button.

Suddenly, the screen freezes and a massive, ugly gray alert box from 1998 pops up saying "Are you sure?"

This is the default browser window.confirm() dialog. It looks terrible, it breaks the modern feel of your app, and you cannot style it with CSS.

For a long time, fixing this required writing a bunch of messy custom Javascript to intercept form submissions. But in modern Rails (using Turbo), overriding this behavior is actually incredibly simple. We can use a single Promise and the native HTML5 <dialog> element to create a beautiful, custom confirmation modal.

Here is exactly how to do it in 3 easy steps.

STEP 1: The Native HTML Dialog

First off, we need the actual modal that will pop up. Instead of importing heavy JavaScript modal libraries, we are going to use the native HTML5 <dialog> element. It is supported in all modern browsers and handles all the annoying overlay math for us.

Open your main application layout file and drop this code right before the closing </body> tag.

<!-- app/views/layouts/application.html.erb -->

<dialog id="turbo-confirm-modal" class="backdrop:bg-black/50 p-6 rounded-xl shadow-xl w-96 bg-white">

  <h3 id="turbo-confirm-message" class="text-xl font-bold mb-6 text-gray-800">
    Are you sure?
  </h3>

  <div class="flex justify-end gap-3">
    <button id="turbo-confirm-cancel" class="px-4 py-2 bg-gray-200 text-gray-800 rounded hover:bg-gray-300">
      Cancel
    </button>

    <button id="turbo-confirm-accept" class="px-4 py-2 bg-red-600 text-white rounded hover:bg-red-700">
      Confirm
    </button>
  </div>

</dialog>

Note: I am using Tailwind classes here for styling. The backdrop:bg-black/50 class automatically dims the background of your app when the dialog opens!

STEP 2: The Javascript Override (The Magic)

By default, when Turbo sees data-turbo-confirm on a button, it calls the browser's confirm() method. We need to tell Turbo to use our new HTML dialog instead.

Open your main Javascript entry file (app/javascript/application.js).

Turbo has a built in method called Turbo.setConfirmMethod(). This method expects us to return a Javascript Promise that resolves to either true (if the user clicks Confirm) or false (if they click Cancel).

Add this code to your file:

// app/javascript/application.js
import "@hotwired/turbo-rails"

Turbo.setConfirmMethod((message, element) => {
  return new Promise((resolve) => {
    // 1. Find our dialog and text element
    const dialog = document.getElementById("turbo-confirm-modal")
    const messageEl = document.getElementById("turbo-confirm-message")

    // 2. Insert the dynamic message from the button
    messageEl.textContent = message

    // 3. Show the modal
    dialog.showModal()

    // 4. Handle button clicks
    const btnAccept = document.getElementById("turbo-confirm-accept")
    const btnCancel = document.getElementById("turbo-confirm-cancel")

    // We use the <dialog> built-in 'close' method and pass it a string value
    btnAccept.onclick = () => { dialog.close("accept") }
    btnCancel.onclick = () => { dialog.close("cancel") }

    // 5. Listen for the dialog to close. 
    // This catches both button clicks AND if the user presses the 'ESC' key!
    dialog.addEventListener("close", () => {
      resolve(dialog.returnValue === "accept")
    }, { once: true }) // 'once: true' automatically removes the event listener after it runs
  })
})

This code is brilliantly simple. We don't have to intercept form submissions or worry about race conditions. We just hold the Turbo request in a Promise until the dialog closes.

STEP 3: Using It In Your App

That's it! You don't need to change how you write your Rails code.

Anywhere in your app, you can use the standard turbo_confirm syntax. Turbo will automatically route the message into your beautiful new modal.

<!-- A standard delete button -->
<%= button_to "Delete Project", project_path(@project), 
      method: :delete, 
      class: "btn-danger",
      data: { turbo_confirm: "Are you sure you want to delete this project? This cannot be undone." } %>

<!-- It also works on links -->
<%= link_to "Sign Out", destroy_user_session_path, 
      data: { turbo_confirm: "Ready to leave?" } %>

Summary

In modern web development, details matter. The default browser alert screams "amateur side project."

By combining:

The native HTML5 <dialog> element.
A Javascript Promise.
Turbo's setConfirmMethod.

We created a reusable, accessible, and easily stylable confirmation system in about 30 lines of code. No React, no heavy modal libraries, and no dirty Javascript hacks.

Rails 8: How to Auto-Generate Social Media Preview Cards

Zil Norvilis — Sun, 26 Apr 2026 23:11:25 +0000

Very often I find myself sharing a link to my new Rails project on Twitter, Discord, or LinkedIn. But when I paste the link, the preview just shows a blank, boring gray box.

If you want your SaaS to look professional, you need OpenGraph (og:image) images. The problem is, if you have a blog with 500 posts, or a directory with 10,000 user profiles, you cannot design 10,000 images manually in Figma.

You could use a third-party API service to generate these screenshots, but they usually charge around $29/month. As a solo developer, I hate adding unnecessary monthly subscriptions.

We can actually build a dynamic screenshot generator directly inside our Rails 8 app using HTML, Tailwind, and a headless browser. Here is exactly how to do it in 5 steps.

STEP 1: The "Card" View

First off, we need to design what our image will look like. Instead of trying to draw images with complex Ruby image-magick libraries, we are just going to build a standard Rails webpage.

Let's create a special route that renders a specific post as a card. The trick here is that standard Twitter/LinkedIn cards are exactly 1200x630 pixels.

# config/routes.rb
resources :posts do
  member do
    get :card_preview # e.g., /posts/1/card_preview
  end
end

Now, create a very simple layout just for these cards so they don't load your app's navbar or footer.

<!-- app/views/layouts/card.html.erb -->
<!DOCTYPE html>
<html>
  <head>
    <script src="https://cdn.tailwindcss.com"></script>
  </head>
  <body class="w-[1200px] h-[630px] m-0 p-0 flex items-center justify-center bg-slate-900 text-white">
    <%= yield %>
  </body>
</html>

And the view itself:

<!-- app/views/posts/card_preview.html.erb -->
<div class="p-16 w-full h-full flex flex-col justify-between">
  <h1 class="text-8xl font-bold"><%= @post.title %></h1>
  <div class="flex items-center text-4xl text-gray-400">
    <span>By <%= @post.author_name %></span>
  </div>
</div>

(In your controller, just remember to render this with render layout: 'card')

STEP 2: The Screenshot Engine (Ferrum)

Now we have a webpage that looks exactly like our desired image. We just need our Rails app to "take a photo" of it.

We will use the Ferrum gem. We talked about Ferrum in my web scraping articles - it connects directly to Chrome without needing slow Selenium webdrivers. It is incredibly fast.

Add it to your Gemfile:

gem 'ferrum'

Run bundle install. (Note: Your server will need Chromium/Chrome installed. If you deploy with Kamal, you just add it to your Dockerfile).

STEP 3: The Generator Service

Let's write a plain Ruby object to handle the screenshot. We want to point Ferrum at our card_preview URL, set the window size to 1200x630, and capture the image.

# app/services/card_generator.rb
require 'ferrum'

class CardGenerator
  def self.capture(url)
    # Boot the headless browser
    browser = Ferrum::Browser.new(
      window_size:[1200, 630],
      timeout: 10
    )

    # Go to our special Rails view
    browser.goto(url)

    # Optional: Wait for any custom fonts or images to load
    browser.network.wait_for_idle 

    # Take the screenshot and save it to a temporary file
    temp_file = Tempfile.new(['card', '.png'])
    browser.screenshot(path: temp_file.path, format: :png)

    browser.quit

    temp_file
  end
end

STEP 4: Attaching the Image (ActiveStorage)

We do not want to boot up a headless browser every single time someone shares our link on Twitter. That will instantly crash your database and eat all your server RAM.

We need to generate the image once when the Post is created, and save it using ActiveStorage.

Ensure your Post model is ready:

# app/models/post.rb
class Post < ApplicationRecord
  has_one_attached :og_image
end

Now, let's use a background job (Solid Queue) to generate and attach the image right after the post is saved.

# app/jobs/generate_og_image_job.rb
class GenerateOgImageJob < ApplicationJob
  queue_as :default

  def perform(post_id)
    post = Post.find(post_id)

    # We use Rails routing helpers to get the full URL
    url = Rails.application.routes.url_helpers.card_preview_post_url(post, host: 'https://myapp.com')

    # Run our Ferrum service
    file = CardGenerator.capture(url)

    # Attach the image to the post
    post.og_image.attach(
      io: File.open(file.path), 
      filename: "og_image_#{post.id}.png", 
      content_type: 'image/png'
    )

    file.close
    file.unlink # Clean up the tempfile
  end
end

Just call GenerateOgImageJob.perform_later(self.id) in an after_create_commit callback on your Post model.

STEP 5: The Meta Tags

The hard part is done! You now have a dynamically generated image attached to your database record.

When a user visits the actual show page of your Post, you just need to tell Twitter and LinkedIn where to find that image.

Open your main application layout file and add the OpenGraph meta tags inside the <head>:

<!-- app/views/layouts/application.html.erb -->
<head>
  <!-- Other standard meta tags... -->

  <% if @post&.og_image&.attached? %>
    <meta property="og:image" content="<%= url_for(@post.og_image) %>">
    <meta name="twitter:card" content="summary_large_image">
  <% end %>
</head>

Summary

That's pretty much it.
Instead of paying a monthly fee to an external API, we used the tools we already have in Rails 8.

We created a 1200x630 HTML view.
We used Ferrum to take a screenshot of that view.
We used Solid Queue to run it in the background.
We used ActiveStorage to save the file permanently.

Your application links will now stand out perfectly on social media, and because you are building the cards using standard ERB and Tailwind, you have 100% control over exactly how they look.

Do you use dynamically generated images for your apps? Let me know your workflow in the comments! 👇

OOP vs Functional Programming Explained for Dummies

Zil Norvilis — Sat, 25 Apr 2026 23:11:24 +0000

I see beginner developers get completely overwhelmed by computer science jargon. You read an article about "Monads," "Polymorphism," or "Immutability," and you feel like you are not smart enough to be a programmer.

If you browse tech Twitter or Reddit, you will see constant wars between developers arguing about whether Object-Oriented Programming (OOP) or Functional Programming (FP) is better.

But what do these terms actually mean? If you strip away the fancy university words, they are just two different ways of organizing how data moves through your app.

Here is the absolute simplest explanation of OOP vs Functional programming, without the computer science degree.

The Mental Model: The Robot vs The Conveyor Belt

Imagine you want to build a system that paints cars red.

The Object-Oriented Way (The Robot):
You build a smart Robot called Car. You give the robot some data (its color is blue). When you want the car painted, you press a button on the robot's back called paint_red!. The robot reaches inside its own body, takes out its blue paint, throws it away, and puts in red paint. The robot has changed itself.

The Functional Way (The Conveyor Belt):
You build a dumb conveyor belt. You put a blue car on the belt. It moves through a machine called PaintRed. The machine does not change the original blue car. Instead, it destroys the blue car, and builds a brand new red car at the end of the belt. The machine remembers nothing. It just takes inputs and spits out new outputs.

CONCEPT 1: Object-Oriented Programming (State)

Ruby, Python, and Java are heavily Object-Oriented. The core idea is that data and the functions that change that data live together in the same box (called a Class/Object).

We call this "State." State is just a fancy word for "remembering things."

Look at this Ruby code representing a bank account:

# Object-Oriented Programming (Ruby)
class BankAccount
  attr_reader :balance

  def initialize(starting_balance)
    @balance = starting_balance
  end

  def deposit(amount)
    @balance = @balance + amount
  end
end

my_account = BankAccount.new(100)
my_account.deposit(50)

puts my_account.balance 
# Outputs: 150

Notice what happened. my_account remembered that it had 100. When we called .deposit(50), it changed its own internal memory. The original 100 is gone forever. This is called Mutation (changing things in place).

CONCEPT 2: Functional Programming (Immutability)

Elixir, Haskell, and Clojure are Functional languages. The core idea here is that data and functions are completely separate.

Functions are just dumb calculators. They don't remember anything. You hand them data, and they hand you back new data.

We call this "Immutability." It is a fancy word for "you are not allowed to change the original data."

Look at how a bank account works in a functional language like Elixir:

# Functional Programming (Elixir)
defmodule BankAccount do
  def deposit(current_balance, amount) do
    current_balance + amount
  end
end

my_balance = 100

# We pass the data INTO the machine. 
# It spits out a brand new value.
new_balance = BankAccount.deposit(my_balance, 50)

IO.puts new_balance 
# Outputs: 150

IO.puts my_balance
# Outputs: 100 (The original data was never touched!)

Notice the difference? The BankAccount module doesn't "hold" any money. It just knows how to do the math. We had to pass my_balance into it, and it gave us a completely new variable back.

CONCEPT 3: Why does this matter?

If both methods get the job done, why do people fight about them?

Why people love OOP:
It is very easy for human brains to understand. We live in an object-oriented world. A dog barks. A user logs in. A bank account receives a deposit. It organizes your code into neat little real-world nouns. This is why frameworks like Ruby on Rails are so incredibly fast for building products.

The problem with OOP:
Because objects "remember" things and change themselves, bugs can be incredibly hard to track down. If your user object has the wrong email address, you have to guess which part of your massive app accidentally changed the email.

Why people love Functional Programming:
It is incredibly safe and predictable. If a function always spits out 4 when you give it 2 + 2, testing it is ridiculously easy. Furthermore, because data is never changed in place, you can run 10,000 functions at the exact same time (Concurrency) across multiple CPU cores, and they will never accidentally overwrite each other's data.

The problem with FP:
It can be hard to learn. If you want to change a user's name nested deep inside a database record, you have to write code that makes a copy of the database, makes a copy of the user, and changes the name on the copy. It feels like a lot of extra steps for simple tasks.

Summary

Don't let the jargon scare you.

OOP = Nouns. Data and functions live together. Objects change themselves.
Functional = Verbs. Data and functions are separate. Data is passed through an assembly line to create new data.

If you are building a standard web app (SaaS, blog, e-commerce), Object-Oriented programming is usually the fastest way to ship. If you are building a chat app that needs to handle 5 million messages a second without crashing, Functional programming is your best friend.

The Developer's Hardware Wallet: A Review of the OneKey Classic 1S

Zil Norvilis — Fri, 24 Apr 2026 23:11:26 +0000

The Developer's Hardware Wallet: A Review of the OneKey Classic 1S

Recently I uploaded a new video reviewing a piece of hardware. If you are a developer, a freelancer, or just someone building in the Web3 space, your digital security is your most valuable asset.

Very often I see developers who are incredibly smart with their code, but they are still keeping their funds in browser extensions (like MetaMask) or on centralized exchanges. That is a massive single point of failure.

I have been looking for a good hardware wallet, and I recently got my hands on the OneKey Classic 1S. It has been gaining huge traction in the developer community. Here is my honest review of why this device makes a lot of sense for coders.

1. The "Open-Source" Advantage

As developers, we hate black boxes. If I am going to trust a piece of plastic to hold my money, I want to know exactly what the software inside it is doing.

This is where OneKey beats the competition. Their firmware is 100% open-source. You do not have to just "trust" the company. You can literally go to their GitHub repository, look through the folders, and audit the code yourself. This is a massive advantage over some of the older, bigger names in the crypto industry that keep their code completely locked down and hidden.

Under the hood, it uses an EAL 6+ certified secure element. Your private keys never touch the internet. Even if your laptop is infected with terrible malware, your assets are physically isolated inside this device. Hackers cannot physically press the "Confirm" button on your desk.

2. Design and Form Factor

The design of the Classic 1S is incredibly minimal. It is about the exact size of a credit card and only 3mm thick.

It feels very sturdy. You can plug it into your computer and it powers up instantly via USB-C, or you can connect it to your phone via Bluetooth. It doesn't feel like a clunky USB thumb drive from 2010; it actually feels like a modern piece of tech.

3. The Software Experience

Usually, hardware wallets have terrible desktop software. You buy a nice physical device, but the app you use to manage your coins looks like it was built 15 years ago.

The software experience is where OneKey really shines. The OneKey App is an all-in-one hub. It is clean, fast, and supports over 100 chains and 30,000 tokens right out of the box. You don't have to manually install "apps" for every single different coin you want to hold.

But for me, the killer feature is the built-in integrations. You can do instant cross-chain swaps, and they even integrated 0-fee Perpetual trading via Hyperliquid directly inside the app. You can do complex crypto actions without ever exposing your private keys to a random website.

Summary

If you hold more than $100 in crypto, you really shouldn't be using a hot wallet. The peace of mind of having physical hardware is worth the small investment.

The Classic 1S hits that perfect "sweet spot." It has high-end, open-source security, but it comes at a price point that actually makes sense for solo developers and freelancers.

OneKey sent this unit over for me to test, and I have been genuinely impressed with their developer-first approach.

If you want to pick one up and upgrade your security, I have an exclusive 10% discount link for my readers.

🛡️ Get 10% off the OneKey Classic 1S here: Check It Out

Stay secure, keep building, and let me know in the comments what hardware wallet you are currently using!

Laravel for Rails Devs: How to Learn the Sister Framework in a Weekend

Zil Norvilis — Thu, 23 Apr 2026 23:22:41 +0000

A Rails Developer’s Cheat Sheet to Learning Laravel

Very often I find myself talking to developers who think Ruby on Rails and PHP are from completely different planets.

But if you are a Rails developer and you look closely at Laravel, you will notice something funny. It looks incredibly familiar. That is because Laravel's creator, Taylor Otwell, openly admits he was heavily inspired by Ruby on Rails.

Laravel is basically the Rails of the PHP world. It has the same MVC structure, the same active record pattern for the database, and the same focus on "Developer Happiness".

If you ever need to work on a Laravel codebase, or if you are just curious about the other side of the fence, you do not need to learn everything from scratch. You just need a translation guide.

Here is exactly how Laravel concepts map to your Rails brain.

CONCEPT 1: The CLI (Artisan vs Rails)

In Rails, you do everything through the bin/rails command. You generate models, run migrations, and open the console.
In Laravel, the command line tool is called Artisan.

Start the server:
- Rails: rails server
- Laravel: php artisan serve
Open the console:
- Rails: rails console
- Laravel: php artisan tinker (Tinker is an amazing REPL built on PsySH)
Run migrations:
- Rails: rails db:migrate
- Laravel: php artisan migrate

When you want to generate a model and a migration at the same time, Laravel has a great shortcut flag (-m):

# Rails
rails generate model Post title:string body:text

# Laravel
php artisan make:model Post -m

Note: Laravel doesn't generate the table columns from the command line by default. You open the generated migration file and write them in PHP.

CONCEPT 2: Dependency Management (Composer)

In Ruby, we use Bundler and a Gemfile.
In PHP, the standard package manager is Composer, and the file is composer.json.

# Rails: Gemfile
gem 'stripe'

// Laravel: composer.json
"require": {
    "stripe/stripe-php": "^10.0"
}

To install packages, instead of running bundle install, you run composer install. Simple as that.

CONCEPT 3: The ORM (Eloquent vs ActiveRecord)

This is where you will feel most at home. Laravel uses an ORM called Eloquent, which uses the exact same Active Record design pattern as Rails.

Your models live in app/Models/ (instead of app/models/). Querying the database looks almost identical, just with PHP syntax (arrows -> instead of dots ., and semicolons at the end).

# Rails
@users = User.where(active: true).order(created_at: :desc).limit(10)
@user = User.find(1)

// Laravel
$users = User::where('active', 1)->orderBy('created_at', 'desc')->take(10)->get();
$user = User::find(1);

Relationships are also very similar. Instead of macros like has_many, you define a method returning the relationship:

// Laravel: app/Models/User.php
class User extends Model
{
    public function posts()
    {
        return $this->hasMany(Post::class);
    }
}

CONCEPT 4: Routing and Controllers

In Rails, all your routes are clumped into config/routes.rb.
Laravel splits them up. Web routes (which have sessions and CSRF protection) go in routes/web.php. API routes go in routes/api.php.

# Rails: config/routes.rb
get '/about', to: 'pages#about'
resources :posts

// Laravel: routes/web.php
Route::get('/about', [PagesController::class, 'about']);
Route::resource('posts', PostController::class);

The Controllers are practically identical. They receive a request, ask the Model for data, and return a view.

CONCEPT 5: Views (Blade vs ERB)

In Rails, we use ERB (.html.erb) to mix Ruby into our HTML.
Laravel uses a templating engine called Blade (.blade.php).

Honestly, Blade is fantastic. It is a bit cleaner than ERB because you don't have to type <%= %> everywhere. You use the @ symbol for logic and double curly braces {{ }} to output variables.

<!-- Rails ERB -->
<% if @user.is_admin? %>
  <h1>Welcome, <%= @user.name %></h1>
<% else %>
  <h1>Access Denied</h1>
<% end %>

<!-- Laravel Blade -->
@if ($user->is_admin)
  <h1>Welcome, {{ $user->name }}</h1>
@else
  <h1>Access Denied</h1>
@endif

CONCEPT 6: The Frontend (Livewire vs Hotwire)

Rails 8 pushes Hotwire (Turbo and Stimulus) to give you that fast, SPA-like feel without writing React.
Laravel has an equivalent called Livewire.

While Hotwire sends HTML over the wire by intercepting standard form submissions, Livewire actually ties PHP component classes directly to your HTML. When a user clicks a button, Livewire makes an AJAX request, runs the PHP method, and morphs the DOM automatically.

Both accomplish the exact same goal: letting backend developers build highly interactive frontends without touching a massive Javascript build step.

Summary

If you know Ruby on Rails, you already know 80% of Laravel. You just need to get used to writing PHP syntax and adding semicolons at the end of your lines.

Gemfile = composer.json
bin/rails = php artisan
ActiveRecord = Eloquent
ERB = Blade
Hotwire = Livewire

Laravel has an incredibly polished ecosystem (Forge for deployment, Nova for admin panels). While my heart still belongs to Ruby, I have massive respect for Laravel. It is proof that the "Majestic Monolith" is still the best way to build software, no matter what language you write it in.

Forem: Zil Norvilis

Build Your Own Cloud Empire: Hosting Unlimited Rails Apps with Kamal 2

The Strategy: The Kamal Proxy

STEP 1: The Base Hardware

STEP 2: Deploying App Number 1

STEP 3: Deploying App Number 2 (Sharing the Server)

STEP 4: Scaling the Empire (The Database Node)

Summary

Images, Volumes, and Containers: Docker Explained in Plain English

1. The Dockerfile (The Recipe)

2. The Image (The Frozen Cake)

3. The Container (The Running Machine)

4. Volumes (The USB Flash Drive)

5. Ports (The Doors)

6. The Registry (The App Store)

Summary

How to Build a Desktop App with Rails 8 and Electron

From Web to Desktop: Wrapping a Rails Hotwire App in Electron

STEP 1: The Electron Setup

STEP 2: The Main Process (Loading Rails)

STEP 3: Handling External Links

STEP 4: The Hotwire Bridge (Stimulus)

Summary

High ROI Testing: The 3 Secrets Every Solo Rails Dev Needs

TIP 1: System Tests > Unit Tests

TIP 2: Embrace Rails Fixtures (Ditch FactoryBot)

TIP 3: Never Hit Real APIs (Use VCR)

Summary

The Importmap Guide to Shadcn: Beautiful UI with Zero Build Step

How to Use Shadcn UI in Rails 8 (Without React or Webpack)

STEP 1: The Reality Check (What are we actually doing?)

STEP 2: Pin the Stimulus Helpers (Importmap)

STEP 3: Stealing the Shadcn Design

STEP 4: Creating Reusable Components (The Rails Way)

Summary

The Secret to Side-by-Side Gem Development in Rails

Stop Pushing to GitHub: How to Test Ruby Gems Locally

STEP 1: The Folder Structure

STEP 2: The Magic Link (path)

STEP 3: Write Code in the Gem

STEP 4: Test it in Rails

STEP 5: The Pro Move (bundle config)

Summary

The Language of the Web: HTTP Basics You Actually Need to Know

HTTP Basics You Must Know As A Web Developer

CONCEPT 1: The Request and Response Cycle

CONCEPT 2: The Verbs (Methods)

CONCEPT 3: Status Codes (The 5 Buckets)

CONCEPT 4: Headers (The Hidden Metadata)

CONCEPT 5: Statelessness (The Goldfish Memory)

Summary

Stop Using Ugly Browser Alerts: Custom Turbo Confirms in Rails 8

STEP 1: The Native HTML Dialog

STEP 2: The Javascript Override (The Magic)

STEP 3: Using It In Your App

Summary

Rails 8: How to Auto-Generate Social Media Preview Cards

STEP 1: The "Card" View

STEP 2: The Screenshot Engine (Ferrum)

STEP 3: The Generator Service

STEP 4: Attaching the Image (ActiveStorage)

STEP 5: The Meta Tags

Summary

OOP vs Functional Programming Explained for Dummies

The Mental Model: The Robot vs The Conveyor Belt

CONCEPT 1: Object-Oriented Programming (State)

CONCEPT 2: Functional Programming (Immutability)

CONCEPT 3: Why does this matter?

Summary

The Developer's Hardware Wallet: A Review of the OneKey Classic 1S

The Developer's Hardware Wallet: A Review of the OneKey Classic 1S

1. The "Open-Source" Advantage

2. Design and Form Factor

3. The Software Experience

Summary

Laravel for Rails Devs: How to Learn the Sister Framework in a Weekend

A Rails Developer’s Cheat Sheet to Learning Laravel

CONCEPT 1: The CLI (Artisan vs Rails)

CONCEPT 2: Dependency Management (Composer)

CONCEPT 3: The ORM (Eloquent vs ActiveRecord)

STEP 2: The Magic Link (`path`)

STEP 5: The Pro Move (`bundle config`)