DEV Community: Zil Norvilis

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.

Stop Leaking API Keys: Managing Secrets in Kamal 2

Zil Norvilis — Mon, 11 May 2026 23:07:00 +0000

I see developers make a mistake that can ruin their entire month.

They are building a new Rails SaaS. They get their Stripe secret key, their OpenAI key, and their AWS credentials. To deploy the app, they create a file called .env.production on their laptop, paste the keys inside, and deploy.

Then, late on a Friday night, they accidentally type git add . and push that file to a public GitHub repository.

Within exactly 4 seconds, automated bots scrape those keys. By Saturday morning, hackers have spun up $50,000 worth of crypto-mining servers on their AWS account.

As a solo developer, you cannot afford this mistake. You need a system where your production secrets never touch a file that can be committed to Git.

With the release of Kamal 2, managing secrets has been completely overhauled. You can now pull your API keys directly from your password manager during the deployment process. Here is how to lock down your Rails app in 4 simple steps.

STEP 1: The `deploy.yml` Configuration

In Kamal 2, you explicitly tell your deployment configuration which environment variables are considered "secrets".

Open your config/deploy.yml file. You will see an env section. You just list the names of the keys your Rails app expects.

# config/deploy.yml
env:
  clear:
    # Safe to commit (Public info)
    RAILS_ENV: production
    POSTGRES_USER: my_app_user
  secret:
    # DANGEROUS! Do not put the actual values here!
    - RAILS_MASTER_KEY
    - POSTGRES_PASSWORD
    - STRIPE_SECRET_KEY
    - OPENAI_API_KEY

When you run kamal deploy, Kamal looks at this list and says: "Okay, I need to find the values for these 4 secrets before I can boot up the Docker container."

STEP 2: The `.kamal/secrets` File

So, where does Kamal look for the actual values?

By default, Kamal 2 looks for a file on your local machine at .kamal/secrets.
CRITICAL: Ensure this file is added to your .gitignore immediately so it never ends up on GitHub.

You can create this file and paste your keys into it:

# .kamal/secrets
RAILS_MASTER_KEY=abc123supersecret...
POSTGRES_PASSWORD=databasepassword99!
STRIPE_SECRET_KEY=sk_live_55555...

When you deploy, Kamal reads this file, injects the secrets securely into the Docker container, and boots the app.

This is much better than hardcoding keys in your codebase. But we can do even better. We can remove the keys from our hard drive completely.

STEP 3: The "Pro Move" (Password Manager CLI)

Having plain text passwords sitting in .kamal/secrets on your laptop is still risky. If your laptop gets stolen, the keys are compromised.

Kamal 2 allows you to execute terminal commands inside the .kamal/secrets file. This means we can ask a Password Manager (like 1Password, Bitwarden, or LastPass) to fetch the keys from the cloud at the exact moment of deployment.

I use 1Password. I installed their command-line tool (the op CLI).

Instead of writing the actual API key in my file, I write the 1Password command to fetch it:

# .kamal/secrets

# Fetch the master key from my 1Password vault
RAILS_MASTER_KEY=$(op read "op://Work/RailsApp/master_key")

# Fetch the database password
POSTGRES_PASSWORD=$(op read "op://Work/Database/password")

# Fetch the Stripe key
STRIPE_SECRET_KEY=$(op read "op://Work/Stripe/secret_key")

STEP 4: The Secure Deploy

Now, let's see what happens when I deploy my app.

I open my terminal and type:

kamal deploy

Kamal reads .kamal/secrets.
It sees the op read commands.
1Password pops up on my screen, asking for my fingerprint (TouchID).
I scan my finger.
1Password securely hands the keys to Kamal in memory.
Kamal pushes the keys to the server and boots the app.

The plain-text keys do not exist anywhere on my laptop's hard drive. They live securely in the 1Password cloud, and are injected directly into the production server's memory.

Summary

Security as a solo developer is usually an afterthought until something terrible happens.

By using Kamal 2's secret management, you completely eliminate the risk of the dreaded "leaked .env file."

List the variable names in deploy.yml.
Put the values (or the fetch commands) in .kamal/secrets.
Keep your .gitignore clean.
Use a password manager CLI to never store plain text keys locally.

This setup takes about 10 minutes to configure, but the peace of mind it gives you when you run git push on a Friday night is priceless.

The Solo Developer’s Secret Weapon: Self-Hosted Automation with n8n

Zil Norvilis — Sun, 10 May 2026 23:04:47 +0000

Automating My Life: How I Use n8n Instead of Custom Ruby Scripts

Very often I find myself falling into the classic developer trap.

I need a system that checks my Stripe account every morning, finds any failed payments, matches them to a user in my Rails database, and sends an alert to a private Discord channel.

My immediate instinct as a developer is: "I can build that in an hour."

So, I create a new StripeAlertJob in Rails. I write a custom HTTP request to Discord. I schedule it with Sidekiq. It works perfectly.

But six months later, the Discord API changes. Or Stripe updates their gem. Or the job silently fails and I don't notice. Suddenly, I am spending my Saturday morning debugging "glue code" that has absolutely nothing to do with my actual core product.

As a solo developer, your time is your most precious asset. You should not be writing and maintaining code for basic integrations.

In 2026, my solution to this is n8n. It is a visual, node-based automation tool (like Zapier), but built for developers. Here is why I stopped writing custom Ruby scripts and moved all my "glue" logic to n8n.

What is n8n? (And why not Zapier?)

If you are a developer, you probably hate Zapier. It is insanely expensive (often costing hundreds of dollars a month for a busy app), the error logs are terrible, and doing complex logic like loops or custom HTTP requests feels clunky.

n8n is different.

It is "fair-code" open source. You can self-host it on a cheap $5 Hetzner VPS using Docker.
It allows you to write raw JavaScript inside the nodes if you need custom logic.
It has built-in nodes for almost everything (Stripe, GitHub, Postgres, Discord, OpenAI).

Here is how I use it to replace my custom Ruby scripts.

USE CASE 1: The "New User" Onboarding Flow

When a user signs up for my Rails SaaS, I want a few things to happen:

Add them to a Beehiiv newsletter list.
Send me a Slack/Discord notification.
If their email ends in @google.com or @microsoft.com, flag them as a high-value lead in a Google Sheet.

The Old Way (Rails):
I would install three different gems (beehiiv, slack-notifier, google-drive-ruby). I would write a massive UserOnboardingService.rb class and manage API keys for all three services in my .env file.

The n8n Way:
I write exactly one line of code in my Rails app. I trigger an empty Webhook.

# app/controllers/users/registrations_controller.rb
def create
  @user = User.new(user_params)
  if @user.save
    # Just throw the user data at n8n and forget about it
    HTTP.post("https://n8n.mydomain.com/webhook/new-user", json: @user.as_json)

    redirect_to root_path
  end
end

Inside the n8n visual editor, I catch that Webhook. I drag and drop a line to the Beehiiv node, a line to an If node (checking for @google.com), and a line to a Discord node.

If any of those APIs fail or change, n8n handles the retry logic and sends me an error alert. My Rails app stays incredibly lightweight and completely unaware of external marketing tools.

USE CASE 2: The Nightly Database Report

I love getting a daily summary of my business metrics (New users, MRR, Active sessions).

Normally, I would write a custom Rake task (rake reports:daily) and use a Cron job on my server to trigger it.

With n8n, I don't even touch the Rails app.
n8n has a native PostgreSQL node.

I set a Schedule Trigger for 8:00 AM.
I add a Postgres node. I give it read-only access to my production Rails database.
I write raw SQL directly inside the n8n node: SELECT COUNT(*) FROM users WHERE created_at > NOW() - INTERVAL '1 day';
I pass the result to an OpenAI node and tell the AI: "Summarize these metrics into a friendly morning greeting."
I pass the AI's output to a Telegram node which messages my phone.

Zero Ruby code written. Zero gems installed.

The Self-Hosted Workflow

Because n8n is just a Docker container, deploying it alongside your Rails app is incredibly easy, especially if you are using Kamal.

I just spin up a tiny $5 VPS specifically for my internal tools. I use Docker Compose to run n8n, point a subdomain to it (automations.mycompany.com), and I have an enterprise-grade automation engine running for the price of a cup of coffee.

Summary

As engineers, our ego often tells us that writing code is always the best solution.

But every line of code you write is a line of code you have to maintain, test, and debug. If you are building a feature that provides unique value to your customers, write the Ruby code.

If you are just moving data from Point A to Point B, generating alerts, or syncing marketing lists? Use n8n.

Offloading the "glue work" keeps your Rails monolith clean, keeps your mind focused, and lets you automate your business visually.

Killing the Password: How to Add Passkeys to Your Rails 8 App

Zil Norvilis — Sat, 09 May 2026 23:04:55 +0000

Very often I see users struggling with the absolute worst part of the internet: Passwords.

They forget them. They use "Password123" and get hacked. They get annoyed when your app forces them to include a special character and an uppercase letter. As a solo developer, building "Forgot Password" flows and dealing with compromised accounts is a massive waste of time.

In 2026, the industry is finally killing the password. Apple, Google, and Microsoft have all standardized Passkeys (WebAuthn).

This means your users can log into your Rails app using their laptop's TouchID, FaceID, or Windows Hello. It is incredibly secure (phishing-proof) and the UX is magical.

Adding this to a Rails app sounds terrifying because cryptography is hard. But thanks to the webauthn gem, we can implement it without needing a PhD in math. Here is the step-by-step guide to adding Passkeys to your Rails app.

The Mental Model: How Passkeys Work

Before we write code, you must understand the flow. It is a simple two-step dance:

The Challenge: Your Rails server generates a random string of gibberish (a "challenge") and sends it to the browser.
The Signature: The browser asks the user for their fingerprint. The hardware securely signs the gibberish and sends it back. Rails verifies the signature.

You never store a password. You only store a Public Key.

STEP 1: The Database Setup

We need to store the devices (Passkeys) that the user registers. A user can have many passkeys (e.g., their iPhone and their Macbook).

First, our User model needs a unique, random ID for WebAuthn.

rails g migration AddWebauthnIdToUsers webauthn_id:string:uniq

Second, we need a model to store the actual Passkey hardware devices.

rails g model Passkey user:references external_id:string:uniq public_key:string sign_count:integer
rails db:migrate

Note: Ensure your User model automatically generates a webauthn_id (like SecureRandom.uuid) when a new user is created.

STEP 2: The Gem and Configuration

Add the official WebAuthn gem to your Gemfile:

gem 'webauthn'

Run bundle install.

Now, we need a quick initializer to tell the gem what our website's domain is.
Create config/initializers/webauthn.rb:

WebAuthn.configure do |config|
  # This should be your actual production domain
  config.origin = "http://localhost:3000" 
  config.rp_name = "My Awesome SaaS"
end

STEP 3: The Backend Logic (Registration)

When a user wants to register their fingerprint, they click a button. This triggers a request to our controller.

We need two actions: one to generate the "Challenge", and one to verify the "Response" the browser sends back.

# app/controllers/passkeys_controller.rb
class PasskeysController < ApplicationController
  # 1. Generate the options and the challenge
  def create_options
    options = WebAuthn::Credential.options_for_create(
      user: { 
        id: current_user.webauthn_id, 
        name: current_user.email 
      }
    )

    # We must save the challenge in the session so we can verify it later
    session[:creation_challenge] = options.challenge

    render json: options
  end

  # 2. Verify the fingerprint response
  def create
    webauthn_credential = WebAuthn::Credential.from_create(params[:credential])

    begin
      webauthn_credential.verify(session[:creation_challenge])

      # If it passes, save the public key to the database!
      current_user.passkeys.create!(
        external_id: webauthn_credential.id,
        public_key: webauthn_credential.public_key,
        sign_count: webauthn_credential.sign_count
      )

      render json: { status: "ok" }
    rescue WebAuthn::Error => e
      render json: { error: e.message }, status: :unprocessable_entity
    end
  end
end

STEP 4: The Javascript (Stimulus)

This is usually where developers get stuck. The native browser API for WebAuthn expects raw binary data (ArrayBuffers), but Rails sends JSON.

To make this perfectly smooth, GitHub created a tiny wrapper library that handles the conversion. We pin it using Importmaps:

bin/importmap pin @github/webauthn-json
rails g stimulus passkey

Now we write a clean Stimulus controller. It fetches the options from Rails, asks the browser for the fingerprint, and sends the result back.

// app/javascript/controllers/passkey_controller.js
import { Controller } from "@hotwired/stimulus"
import { create, get } from "@github/webauthn-json"

export default class extends Controller {

  async register() {
    // 1. Get the challenge from our Rails controller
    const response = await fetch('/passkeys/create_options', { method: 'POST' })
    const options = await response.json()

    try {
      // 2. This triggers the MacOS TouchID / Windows Hello popup!
      const credential = await create({ publicKey: options })

      // 3. Send the hardware signature back to Rails
      const verifyResponse = await fetch('/passkeys', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ credential: credential })
      })

      if (verifyResponse.ok) {
        alert("Passkey registered successfully!")
      }
    } catch (error) {
      console.error("Passkey registration failed", error)
    }
  }
}

In your view, you just add a button:

<div data-controller="passkey">
  <button data-action="click->passkey#register">
    Register Fingerprint / FaceID
  </button>
</div>

What about Logging In?

The login flow is exactly the same concept, just using options_for_get instead of options_for_create.

User types their email.
Rails generates a login challenge.
Stimulus calls get({ publicKey: options }) which prompts TouchID.
Rails verifies the signature, looks up the Passkey by its external_id, finds the attached User, and logs them in!

Summary

Killing the password entirely might be too aggressive for a brand new startup (you still need a fallback for older devices). But adding Passkeys as an alternative login method makes your app feel incredibly premium.

Security: No database leaks can expose passwords, because you only store public keys.
UX: Clicking a button and touching a fingerprint scanner takes 1 second. Typing a 16-character password takes 15 seconds.
The Tools: By combining webauthn-ruby, @github/webauthn-json, and Stimulus, we avoid all the painful cryptography math.

Embrace the future. Let your users log in with their faces.

10 Crypto Disasters That Shook the World (And What They Teach Coders)

Zil Norvilis — Fri, 08 May 2026 23:19:36 +0000

In the world of cryptocurrency, we often say that "code is law." But when that law has a bug, or the person writing the law is a thief, billions of dollars can vanish in a single block.

From algorithmic death spirals to the greatest heists in human history, the blockchain has seen some massive disasters. These aren't just stories about lost money; they are hard lessons for every developer and "coderpreneur" building in this space.

Here are the 10 biggest crypto disasters that shook the industry to its core.

10. Celsius Network (2022)

Celsius promised to "unbank" the world by offering safe yields of up to 18%. In reality, CEO Alex Mashinsky was gambling with user funds in high-risk DeFi protocols. When the market crashed in 2022, Celsius froze withdrawals, locking 1.7 million people out of $4.7 billion.
The Lesson: If you don't know where the yield is coming from, you are the yield.

9. The Poly Network Hack (2021)

A hacker exploited a vulnerability in how this protocol verified cross-chain transactions, stealing $611 million. In a strange turn of events, the hacker started chatting with the developers on the blockchain and eventually returned almost all the money.
The Lesson: Cross-chain bridges are currently one of the most fragile points in the ecosystem.

8. The Bitfinex Hack (2016)

Nearly 120,000 Bitcoin were stolen from the exchange. At the time, it was worth $72 million; today, it is worth billions. Years later, a couple in New York was arrested for trying to launder the funds.
The Lesson: The blockchain is a permanent ledger. It never forgets a crime, even years later.

7. The DAO (2016)

The DAO was a decentralized organization that raised $150 million in ETH. A "recursive call" bug in the smart contract allowed an attacker to drain a third of the funds. This was so big it forced Ethereum to do a "Hard Fork," splitting the community.
The Lesson: Even "unstoppable code" is subject to human intervention when enough money is at stake.

6. QuadrigaCX (2019)

Canada’s largest exchange collapsed because its founder, Gerald Cotten, was the only person with the private keys to the "cold storage" wallets. When he reportedly died in India, $190 million in customer funds were trapped forever.
The Lesson: Centralized points of failure are the enemy of decentralization.

5. The Ronin Bridge Hack (2022)

Axie Infinity was the king of blockchain gaming, but its bridge to Ethereum was weak. Hackers managed to compromise five out of nine validator nodes to steal $625 million.
The Lesson: A blockchain is only as secure as its most vulnerable validator.

4. BitConnect (2018)

The ultimate Ponzi scheme. BitConnect promised 1% daily interest through a "trading bot" that didn't actually exist. It reached a $2.6 billion market cap before the pyramid collapsed.
The Lesson: If it sounds too good to be true, it’s a scam.

3. Mt. Gox (2014)

Mt. Gox handled 70% of all Bitcoin transactions globally. When they announced they "lost" 850,000 Bitcoins to a multi-year hack, the industry nearly died.
The Lesson: Bitcoin is secure, but the exchanges we use to buy it are often the weakest link.

2. FTX (2022)

Sam Bankman-Fried was the "golden boy" of crypto, but it was all a front. FTX was funneling customer deposits to cover massive gambling losses at its sister firm, Alameda Research. $8 billion evaporated overnight.
The Lesson: Old-school corporate fraud can easily hide behind new-age tech.

1. Terra LUNA (2022)

This was a mathematical collapse. Terra’s stablecoin (UST) was pegged to the dollar using an algorithm. When the peg broke, it triggered a "death spiral" that wiped out $40 billion in a few days.
The Lesson: Complexity is the enemy of security.

How to Protect Yourself

The recurring theme in almost all these disasters is Trust. People trusted their life savings to third parties - exchanges, "yield" platforms, or centralized founders.

When you don't own your private keys, you don't own your money. This is why every developer and builder should use a hardware wallet for their main assets.

I personally recommend OneKey. Their hardware is fully open-source, meaning the code is transparent and can be audited by the community. There are no hidden backdoors.

🛡️ Protect your assets and get 10% off your OneKey device using THIS LINK:

Summary

The history of crypto is written in red ink, but every disaster makes the ecosystem more resilient. As builders, we must remember that there is no "undo" button on the blockchain. Stay safe, keep your keys private, and keep building.

Hotwire Native vs NativePHP: How Web Frameworks are Conquering Mobile and Desktop

Zil Norvilis — Thu, 07 May 2026 23:08:17 +0000

Hotwire Native vs NativePHP: How Web Frameworks are Conquering Mobile and Desktop

Very often I find myself talking to developers who have successfully launched a web application. They are getting traffic, users are happy, but eventually, the inevitable happens.

A user emails them: "When is the mobile app coming out? Do you have a Mac desktop app?"

If you are a solo developer, learning Swift for iOS, Kotlin for Android, and C++ for Windows is impossible. You want to use the language you already know.

The two biggest backend communities - Ruby on Rails and Laravel (PHP)—both realized this pain point. They both created incredible, massive open-source tools to solve it. Rails gave us Hotwire Native, and the Laravel community gave us NativePHP.

But if you look under the hood, these two tools took completely opposite architectural paths. Here is my breakdown of how Hotwire Native and NativePHP work, the pros and cons of each, and why they solve two very different problems.

1. Hotwire Native: The "Thin Client" (Rails)

Hotwire Native (formerly Turbo Native) is the Rails way of getting your app onto iOS and Android.

How it works:
It is a "Thin Client". When a user downloads your app from the App Store and opens it, they are essentially opening a highly-optimized, invisible web browser.

The mobile app does not have a database. It does not have business logic. When the user taps a button, the app sends a request to your live Rails server, fetches the HTML, and displays it.

The magic is that it intercepts the clicks and uses real native mobile animations (like sliding screens and native bottom tabs) to move between pages.

The Good:

One Codebase, One Database: You only have one Rails app. If you change a typo on the pricing page, it instantly updates for all web, iOS, and Android users. No App Store reviews needed.
Tiny App Size: Because the app is just a shell, the download size is incredibly small.

The Bad:

Requires Internet: Because the server does all the work, if the user loses cell service, the app stops working. You cannot build a true "Offline-First" app this way.

2. NativePHP: The "Local Server" (Laravel)

NativePHP blew the minds of the Laravel community when it launched. It was built primarily to get PHP apps onto Mac and Windows Desktop environments.

How it works:
It takes the exact opposite approach to Hotwire. It is a "Thick Client".

When you package your app with NativePHP, it uses Electron (or Tauri) as a shell. But here is the crazy part: It literally bundles a complete PHP runtime and a SQLite database inside the app.

When your user downloads your .dmg or .exe file, they are silently installing a mini-server on their computer. When they click a button, the PHP code runs locally on their CPU, and saves data to a local SQLite database on their hard drive.

The Good:

True Offline Capability: The app works perfectly on an airplane with no Wi-Fi.
Deep OS Integration: NativePHP gives you simple PHP methods to interact with the operating system. You can create system tray icons, trigger native OS notifications, and read local files easily.

The Bad:

Massive File Sizes: You are shipping a browser, a PHP runtime, and a database to every user. The app size will be massive compared to a native app.
The Syncing Nightmare: If your app has a cloud component (like syncing notes between a desktop and a phone), you now have to write extremely complex logic to merge the user's local SQLite database with your central cloud database.

The Architectural Showdown

Both of these tools are masterpieces of engineering, but they serve two very different philosophies for the solo developer.

If you are building a SaaS, a Marketplace, or a Social Network, Hotwire Native is the absolute winner. In a SaaS, the data must live in the cloud. Having a local database on the user's device (like NativePHP does) creates terrifying data-syncing problems. With Hotwire Native, you manage one Postgres database, and the mobile app is just a beautiful window looking into it.

If you are building a Utility Tool, a Markdown Editor, or a Local File Manager, NativePHP is brilliant. You don't want a markdown editor to stop working because the internet went down. The fact that a PHP developer can build a fast, offline Mac app that lives in the menu bar, without learning Swift or Rust, is a massive achievement.

Summary

In 2026, you do not need to be a polyglot to ship cross-platform apps.

Use Hotwire Native (Rails) to wrap your cloud-based SaaS into a beautiful, lightweight mobile app.
Use NativePHP (Laravel) to bundle your web skills into a heavy, offline-capable desktop utility.

Stop worrying about learning mobile or desktop languages. Stick to the backend framework you love, use the wrappers the community built for you, and keep shipping products.

Stop Fearing OOP: A Simple Guide to Ruby Classes for Beginners

Zil Norvilis — Wed, 06 May 2026 23:08:18 +0000

The Blueprint and the House: Ruby Classes and Objects Explained

Very often I see new developers hit a massive brick wall when they start learning Ruby. You understand variables, you understand if/else statements, and you understand loops.

But then, a tutorial introduces the words "Class" and "Object". Suddenly, the code is full of @ symbols, def initialize, and .new. If you don't have a computer science background, this jargon feels incredibly intimidating.

You do not need a university degree to understand this. You just need a good mental model.

Here is the absolute simplest way to understand Classes and Objects in Ruby, without the heavy academic vocabulary.

The Mental Model: The Blueprint vs. The House

Imagine you are an architect. You sit down and draw a Blueprint for a house. The blueprint says the house will have 2 doors, 3 windows, and be painted a specific color.

Can you live inside a blueprint? Can you open the doors of a blueprint?
No. It is just a piece of paper. It is a set of instructions.

To actually live in it, you have to hire a builder to read the blueprint and construct a Real House out of wood and bricks. You can use that exact same blueprint to build 50 different houses on the same street. Some owners might paint their house red, and others might paint it blue, but they all came from the same instructions.

The Class is the Blueprint.
The Object is the Real House.

Let's look at how this translates into Ruby code.

1. Creating the Blueprint (The Class)

In Ruby, we write a Class to define the rules of our concept. Let's stick with our house example.

class House
  # This is just the blueprint. 
  # It doesn't physically exist in our app's memory yet.
end

Right now, this code does absolutely nothing. It is just a piece of paper sitting on your desk.

2. Building the House (The Object)

To turn our blueprint into something real that we can interact with, we have to "build" it. In Ruby, we do this using the .new method.

# We are building two distinct physical houses from the same blueprint
my_house = House.new
your_house = House.new

When you type House.new, Ruby reads your class, allocates physical memory in your computer, and creates a living, breathing Object. my_house and your_house are two completely separate objects.

3. The Front Door (Initialize)

When a house is built, certain things need to happen immediately. The builder needs to paint it and give the owner the keys.

In Ruby, we use a special method called initialize. Think of this as the "Builder". Whenever you call .new, Ruby automatically looks for the initialize method and runs it first.

class House
  def initialize(color)
    puts "Building a brand new #{color} house!"
  end
end

my_house = House.new("Red")
# Outputs: Building a brand new Red house!

4. The Backpack (Instance Variables)

Here is where beginners get confused. What is the @ symbol?

Imagine every Object wears a little backpack. Inside that backpack, it keeps its own private data. If my_house is Red, and your_house is Blue, they need a way to remember their own colors.

In Ruby, any variable that starts with an @ is an Instance Variable. This means it goes directly into the Object's backpack. It remembers this data forever.

class House
  def initialize(color)
    # Put the color into this specific object's backpack
    @color = color 
  end

  def what_color_am_i?
    # Look inside the backpack and read the color
    "I am a #{@color} house."
  end
end

my_house = House.new("Red")
your_house = House.new("Blue")

puts my_house.what_color_am_i?  # Outputs: I am a Red house.
puts your_house.what_color_am_i? # Outputs: I am a Blue house.

Notice how they don't get confused? my_house looked in its own backpack. your_house looked in its own backpack. They share the same blueprint, but they have their own unique memory.

5. The Actions (Methods)

Finally, Objects need to do things. A house has doors you can open. A user has a password they can reset. An invoice has a total it can calculate.

We define these actions by writing normal methods (def) inside the Class.

class House
  def initialize(color)
    @color = color
    @door_open = false # Doors are closed by default
  end

  def open_door!
    @door_open = true
    puts "The door is now open."
  end
end

my_house = House.new("Red")
my_house.open_door!

Summary

Don't let the computer science vocabulary intimidate you.

Class: The written instructions (Blueprint).
Object (or Instance): The actual thing built from those instructions (The House).
.new: The command to hire the builder and construct the object.
initialize: The setup tasks the builder does on day one.
@variable: The private backpack where the object remembers its own data.
Methods: The actions the object can perform.

Everything in Ruby is an object. A String is an object built from the String class blueprint. An Integer is an object built from the Integer blueprint. Once you grasp this simple idea, the entire Ruby language opens up and starts to feel like plain English.

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.

DEV Community: Zil Norvilis

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

The Problem: The "Tax Nexus" Nightmare

The Solution: The Merchant of Record (MoR)

The Trade-Offs

1. The Fees are Higher

2. The Integration is Slightly Different

3. Less Control Over the Checkout

Summary

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

The Mental Model: What are Embeddings?

STEP 1: The Database Setup

STEP 2: Generating the Embeddings

STEP 3: The Vector Search (Finding the Context)

STEP 4: The RAG Prompt

Summary

Background AI: Using Solid Queue for Slow OpenAI API Calls

STEP 1: The Empty State View

STEP 2: The Fast Controller

STEP 3: The Solid Queue Job

STEP 4: The Broadcast Partial

Summary

Stop Leaking API Keys: Managing Secrets in Kamal 2

STEP 1: The deploy.yml Configuration

STEP 2: The .kamal/secrets File

STEP 3: The "Pro Move" (Password Manager CLI)

STEP 4: The Secure Deploy

Summary

The Solo Developer’s Secret Weapon: Self-Hosted Automation with n8n

Automating My Life: How I Use n8n Instead of Custom Ruby Scripts

What is n8n? (And why not Zapier?)

USE CASE 1: The "New User" Onboarding Flow

USE CASE 2: The Nightly Database Report

The Self-Hosted Workflow

Summary

Killing the Password: How to Add Passkeys to Your Rails 8 App

The Mental Model: How Passkeys Work

STEP 1: The Database Setup

STEP 2: The Gem and Configuration

STEP 3: The Backend Logic (Registration)

STEP 4: The Javascript (Stimulus)

What about Logging In?

Summary

10 Crypto Disasters That Shook the World (And What They Teach Coders)

10. Celsius Network (2022)

9. The Poly Network Hack (2021)

8. The Bitfinex Hack (2016)

7. The DAO (2016)

6. QuadrigaCX (2019)

5. The Ronin Bridge Hack (2022)

4. BitConnect (2018)

3. Mt. Gox (2014)

2. FTX (2022)

1. Terra LUNA (2022)

How to Protect Yourself

Summary

Hotwire Native vs NativePHP: How Web Frameworks are Conquering Mobile and Desktop

Hotwire Native vs NativePHP: How Web Frameworks are Conquering Mobile and Desktop

1. Hotwire Native: The "Thin Client" (Rails)

2. NativePHP: The "Local Server" (Laravel)

The Architectural Showdown

Summary

Stop Fearing OOP: A Simple Guide to Ruby Classes for Beginners

The Blueprint and the House: Ruby Classes and Objects Explained

The Mental Model: The Blueprint vs. The House

1. Creating the Blueprint (The Class)

2. Building the House (The Object)

3. The Front Door (Initialize)

4. The Backpack (Instance Variables)

5. The Actions (Methods)

Summary

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)

STEP 1: The `deploy.yml` Configuration

STEP 2: The `.kamal/secrets` File