Spree 6.0 is a complete redesign and rewrite of Spree Core. It's the biggest Spree release yet!

Marketplace & Multi-Vendor

Run, manage, and monitor your marketplace on Spree Commerce:

• Invite sellers, onboard them, approve or suspend them
• Decide what a seller must do before they can trade — accept terms, add a returns address, connect a bank account, upload a business registration
• Commission by seller, category or product, with VAT handled correctly
• Review and approve a seller's products before they go live
• One payment from the shopper even when the basket spans sellers, split behind the scenes
• A ledger of what every seller earned and what you've paid them
• Stripe Connect built-in: sellers onboard themselves, money splits automatically
• Sellers get their own back office — white-label it — and their own API
• Pay sellers through your own rails with a payout provider
• Seller Dashboard React application you can easily customize and make it on brand

B2B & Wholesale

B2B buyers need different prices, rules, and paperwork than retail shoppers, and Spree 6.0 fully delivers on this front:

• Set up a customer's whole organisation — head office, divisions, branches — and who may buy for which part, with Companies
• Let a buyer invite their own colleagues instead of emailing you
• Show each customer their own prices, their own product selection, or both, with Catalogs
• Enforce minimum quantities and pack multiples — 48 minimum, in 24s, so 72 is fine, and 50 isn't
• Set a minimum value for the whole order
• Capture the buyer's purchase order number at checkout
• Tax exemption certificates and VAT IDs, validated automatically
• Sell by the pallet, not just the parcel - define your own cartons, pallets and containers, and get freight totals on every order

AI-native end-to-end

Both developers and merchants can easily connect Spree to their AI agents:

• Develop with agents with our collection of Agent Skills
• Manage your store with Admin MCP server - connect Claude, ChatGPT, Cursor, and others with ease!

Cross-Border & Tax Compliance

Cross-border selling breaks on tax and duties more often than on language.

• Plug in Avalara or similar instead of maintaining rates yourself
• Capture a business customer's VAT number and apply EU reverse charge correctly
• Charge customs duties and import fees as their own line, shown at checkout
• Classify products with commodity codes and country of origin, so labels carry a proper declaration
• Record why something was taxed the way it was — for e-invoicing and audits
• Markets with their own currencies, languages and tax treatment
• Omnichannel: channels for web, app, retail POS or wholesale, each with its own rules

Inventory & Warehouse Management

Most platforms tell you what you have. Few help you get more of it.

• Raise purchase orders to suppliers and keep a supplier list — see Inventory
• Record what actually arrived, including damage and shortfalls
• See why every stock movement happened and which document caused it
• Reserve stock so two shoppers can't buy the last one
• Stock comes off the shelf when goods ship, not when the order is placed
• Restrict a sales channel to specific warehouses — your trade channel ships only from the trade warehouse
• Connect your ERP and let it stay the authority on stock

Shipping & Fulfillment

• Live carrier rates at checkout instead of flat-rate guesses. EasyPost integration out of the box.
• Buy postage in Spree, or upload a label you bought elsewhere — see Fulfillments
• Tracking updates flow back automatically
• Click and collect, with real pickup locations
• Charge by postcode — free local delivery, island surcharges, city-only express
• Say which warehouses ship which products, in delivery setup
• Offer or hide a delivery method by basket value, weight or contents — no code
• Connect a warehouse or 3PL and let them fulfil
• Define package types, freight options and cartons

Payments & Checkout

• Modern checkout for Stripe, Adyen and PayPal — wallets, BNPL, bank transfers
• Charge now, on dispatch, or manually — see Payments
• Saved cards for returning customers
• Orders complete even if the customer closes the tab mid-payment
• Offline methods too: cheque, bank transfer, cash on delivery
• Fully PCI-Compliant

Returns & Post-Purchase

• Returns, exchanges and damage claims, each tracked properly
• Your own rules for what's returnable and for how long
• Refunds to the original payment, to store credit, or split
• Buy return labels from the dashboard

Product Information Management

• Product types, so a book and a sofa can ask for different information
• Collections that fill themselves from rules you set
• Custom fields on anything, editable by merchants without a developer
• A media library, with video — or connect your DAM
• Digital products with controlled download links
• Connect your PIM and let it own product data
• Typo-tolerant search and filtering

Pricing & Promotions

• Promotions with stackable rules and generated coupon codes
• Fees and surcharges as their own line, not hidden in the total

Reporting & Analytics

• Reporting is now built-in - the dashboard ships with over 20+ reports, not only on sales but also on your store performance, inventory, and operations
• Your staff can now build reports from the dashboard and share them

Data Privacy & Compliance

Run your EU business with peace of mind - Data Privacy is now a core Spree feature:

• Answer a "send me my data" or "delete me" request without engineering time
• Deleting a customer anonymises them, so your books and tax records stay intact
• Consent records proving what a customer agreed to, and when
• Price history for the EU Omnibus rules
• Right-of-withdrawal windows per market
• Staff roles and permissions you define yourself

React Admin Dashboard

A new Dashboard experience rebuilt from the ground up on a modern tech stack - Vite, TanStack, and React:

• Mobile-ready, super fast, with dark mode
• Add your own pages and screens without forking anything
• Customize existing pages by adding your own components
• Sign staff in with your existing identity provider
• Full RBAC support with UI to manage roles and permissions

Headless & Composable

• One REST API, with fully typed clients for storefront, Admin, and Sellers API
• Start from the Next.js storefront or build your own
• Webhooks and events for everything that happens

DevOps and Observability

• New official Docker image, simplified deployment and management
• Monitor it in production with OpenTelemetry built-in

Installation

Requirements: Node.js 24+ and Docker running.

npx create-spree-app@latest my-store

Upgrading

Upgrading from Spree 5?

npx spree upgrade

The upgrade guide covers every change and ships migration tasks for the data.

Feedback

Feel free to open GitHub issues or join our Discord

The iPhone Duo came out a few days and and I have been having a blast using mine. And so I have been updating my apps which run on Hotwire Native – A platform that let's me put my rails site in an app, with progressive enhancement via little bridges so that parts of my app can have native components. Most of the time you're in a webview, and your rails site only knows what it's told over a bridge, or an API request.

I wanted to make my app increase the gap between columns when the Duo is in book mode (partially folded). There doesn't appear to be a way to get this from the webview itself, so I decided to (get claude to) write my own bridge component.

Introducing Apple Hardware Bridge Component.

Once enabled I can use the following code to respond to the hinge, or if I am on the cover, or the big screen.

<body data-controller="bridge--device" class="group/device safe-padding">
  <main class="grid duo-inner:grid-cols-2 duo-spread">
    <section class="duo-right-page">On the cover, and on the right when open</section>
    <section class="duo-outer:hidden">Only on the big screen</section>
    <p class="hidden duo-book:block">Half open, like a book</p>
  </main>
</body>

Instead of stopping there, I decided it was finally time to fix the issue with safe areas in the webview, these are now sent over the bridge too so you can position your content appropriately.

<body data-controller="bridge--device" class="safe-padding">

.toolbar {
  padding-top: var(--device-occlusion-top);
  padding-right: var(--device-safe-right);
}

And finally, I made it detect all kinds of Apple Hardware! I have tested it on the iPhone Duo, the iPhone Air and the iPad Pro 11-inch (M4). There is a demo app you can build, I would love it if people would test on their devices and let me know how it works.

The sky is the limit now, you could make your webview content change in all kinds of ways based on the angle of the hinge, or the rotation of the device. I am excited to see what people come up with!

Hope you enjoy! Let me know if you build something cool!

I know it is obvious and probably nothing. But the noise reduction in the current world is very important.

A few months ago, I created Hibiki, a small Ruby library that brings Svelte's Rune-style reactivity to Ruby (with Ruby's signals). After creating the gem, I wanted to see what we could do with it in a Rails app - turns out we can do a lot. Over the past few months, I have been developing the Rails glue and testing out patterns that can make the best use of the reactivity Hibiki brings. Now I have something to show you.

The demo site

Please allow me to introduce the website: hibikirb.dev

This is a demo website that showcases what you can do with Hibiki. It covers common advanced tasks that are possible but often tedious or complicated in Rails. A few examples:

• Live Search with reactive filters, search indicators, and pagination
• Dependent Selects for any depth
• Searchable Multi-select with live updates
• Shopping Cart without duplicating logic on the client
• Multi-step Form Wizard with cross-step validation
• Presence and Conflicts with live resolution
• Undo and Redo with keyboard hotkeys

And many more. All of the recipes require no JavaScript of your own. You write your client-side interactions in Ruby (in a Rails channel), and you only write them once.

The concept explained

Here's a code example that explains the whole concept:

class CounterChannel < ApplicationCable::Channel
  include Hibiki::Rails::Channel

  def build_graph
    @count = Hibiki::State.new(0)
    doubled = Hibiki::Derived.new { @count.value * 2 }

    Hibiki::Effect.new do
      broadcast_replace target: "counter_display",
                        partial: "app/recipes/counter/counter_display",
                        locals: { count: @count.value, doubled: doubled.value }
    end
  end

  # Public methods are client-invocable actions; keep helpers private.
  def increment = @count.value += 1
end

In the code above, build_graph is the method that builds a signal graph for this channel. Inside this method, we can define a state, which holds a value; a derived, which computes its value from a state and updates whenever that state changes; and an effect, which is a block that runs immediately and re-runs whenever any state or derived value used inside the block changes.

We also have a channel action, increment, which the client can call through ActionCable. When the client calls increment, the value of the state @count changes, and other values that depend on it - here the doubled and the effect - also update. The result is that the effect re-renders the partial (through a Turbo broadcast in this case) without us explicitly telling it to.

With this simple reactive pattern, we can build surprisingly complex interactions with minimal code, while removing much of the boilerplate that would otherwise be required in Rails. The demo site showcases just how far we can take this approach.

Batteries included

The gem hibiki-rails now comes with fully worked-out CRUD generators that help you create reactive CRUD resources in a matter of seconds. For example, to generate a full Book resource, simply run:

bin/rails g hibiki:rails:scaffold Book title:string available:boolean author:references

Hibiki's scaffold extends Rails' own scaffold, so you'll still find all the usual Rails scaffold files in their expected places. What the generator adds is:

• A live index page with search, filtering, and sorting based on your resource's columns.
• In-place pagination, with optional infinite scroll if you need it.
• An inline create form.
• Inline editing.
• Live validation.
• Live updates - any changes from other sources automatically update the index.

After a resource is created, you can even add additional features to it. For example, if you need a multi-select over a has_many :through association, simply run:

# Creates a searchable multi-select that can handle 100,000 or more records
bin/rails g hibiki:rails:multiselect Album Song Track     # Track is the join model

Need a nested form with multiple levels and sorting? We've got you:

# Adds a credits fieldset to the song's forms; creates Credit
# (and its migration) when missing. song:references is added for you.
bin/rails g hibiki:rails:nested Song Credit role:string position:integer

Need file uploads? Sure:

# Adds a gallery, and allows non-image files
bin/rails g hibiki:rails:upload_field Album photos --many --accept=image,pdf

You can read more about the generators in the docs. This is quite exciting, and it's my favorite feature from developing this gem.

Built for humans and agents

Hibiki is developed to enhance the already-amazing Rails developer experience, but it's also designed for coding agents. Hibiki comes with a full set of agent skills. The skills support coding agents such as Claude Code, Codex, and Cursor, and can be installed in your project with a simple command:

# -a to specify your agent, e.g. codex, gemini-cli, cursor, github-copilot...
npx skills add planetaska/hibiki --skill '*' -a claude-code

In fact, using a coding agent with the skills loaded is a great way to start learning Hibiki's reactive patterns and putting them to use in your project. For example, you can simply ask your coding agent to:

Build a live search for the Books resource using the hibiki pattern.

Or even:

Create a reactive form for Books using the hibiki pattern, with nested fields from its own associations, and with a filterable author select. The publish event dates should have cross-field validation.

AI-assisted development disclosure

As stated before, I developed this gem with Claude's help. I still own the project, decide its direction, and review and revise the code to make sure there isn't a line I wouldn't write myself. My approach is to write a code draft myself, then work with Claude to identify potential issues, and keep a feature only when it is fully worked out. I also spend just as much time, if not more, writing, rewriting, and proofreading all the user-facing documentation. While this gem was developed with the help of coding agents, I still want to make it as human-centered as possible.

Closing

Thank you for reading this long post. I hope you find the gem helpful and enjoy the demo website. If you find this useful, have any questions, or even have feature requests, please feel free to leave a comment. I'm looking forward to hearing feedback from you!

Looking for developers

I am looking for developers who are interested in contributing to Hibiki, helping maintain the gem, improving its Rails integration, documentation, and testing, as well as collaborating on some planned features (still a secret for now). If you're familiar with Ruby or Rails, interested in reactive programming, and would like to help shape the future of this project, feel free to send me a message. I'd be more than happy to discuss how we can work together!

Hey guys!

Thought I'd share the project I've been working on since July, built with Ruby on Rails, PixelGlass.

PixelGlass is a multi-tenant, agent-first platform for running your own community and magazine — two things I'm really passionate about. The idea is to make it easy for anyone to put up a beautiful, interactive site, with the hard parts like email, auth and payments already handled for you and customise it and add content with your favourite Agent.

In practice, every publication gets:

• its own site on its own domain, with themes
• newsletters sent straight from your posts
• members, paid memberships (0% platform fee) and comments
• an MCP server built in, so you can connect Claude or ChatGPT and have your agent write, publish and even redesign the site with you

Under the hood, every publication gets its own tenant, its own database and its own file storage. Backing one up is basically just copying a folder.

I built it the Rails way, following 37signals practices — fat models, thin controllers:

• The editor uses Lexxy, which has been amazing to work with (especially since I've been developing on Lexical since 2022)
• Public themes use Liquid
• The admin is plain Rails ERB with Hotwire and Stimulus. Still surprised how interactive you can make things without touchin React

Having a lot of fun with it, and it's been a really good learning curve, especially on the infrastructure side (multi-tenancy, custom domains, subdomains, wildcard ssl, just to name a few and building the MCP server in particular).

There are 3 production sites on it now, and I'm about to onboard a customer with ~40k subscribers, so that should properly put the performance to the test.

Happy to answer any questions or go deeper on any of it - I've been using Rails for about a year now, coming from a javascript / node / python background.

Really love the Rails community and the ecosystem is incredible!

I built Karpathy's tiny autograd engine built on how neural networks and backpropagation actually work. It was a great to explore foundational ML concepts and also learn the basics of Ruby. Personally, me - who grew up learning C++ as a first language, later changed to Python and haven't attempted to try out other languages it was shocking how well structured this language is!

Did some research on Ruby role in AI... What do you think, can we expect a bigger role for Ruby besides RubyLLM in the future within this field?

Hello everyone! I've finally published my first ever serious Rails application. You can find it here.

Household is an app to manage everything in your life: tasks, appointments, medications, therapies, lab results, meals, ingredients, medical supplies, file sharing and messages between housemates. It also has an agent that works as your bookkeeper. Instead of manually adding things by hand, you can talk to the assistant and it will manage the records for you. It drafts changes to the record for you to apply, edit or undo. Supported providers are: Ollama, Anthropic and OpenAI.

Although third party providers are supported, I recommend using a local Ollama as the agent will deal with sensitive and private information.

For Ollama, I found success with qwen3:8b with a 12k context window.

You can test your own model in the "eval" section. I recommend a passing rate of at least 70-75% on a 3x run. Claude Haiku passes with 100% every single run.

The agent also has a lexicon to match terms in different languages. This is only necessary for multilingual households, where you might have saved a record in a language and then reference it in another language to the assistant. The lexicon is downloaded via kaikki.org, pulling from Wiktionary.

Supported display languages are English and Italian, feel free to contribute your own .yml file if you want to see the app in your language. Everything in the app uses the i18n helper.

Under releases in GitHub, you can download the install.sh script which will guide you through the first setup of the app. You don't need ruby or anything else to run it. The script will also ask how you will serve the app and set it up accordingly (cloudflare, local, tailnet etc).

The app also has a settings page in case you want to change anything later without touching .env. All keys are encrypted in postgres.

This is also my first serious project in Phlex. I bypassed ViewComponents entirely and went from Haml to Phlex directly. I couldn't be happier with Phlex, I really think it's the future of Rails. It fits the framework so well in my opinion.

Let me know what you guys think! You can find a demo of the app here. The demo is accessible to anyone and is reset every night, so be sure not to input any sensitive information in the demo.

The app has been built with the help of various agents, while readme and docs are fully AI generated, so forgive me if they are a bit clunky to read, I will rewrite them asap. They are not wrong, they just have the classic long and confusing sentences typical of AI.

Edit: Formatting

Ok, we have Kamal. It's great, but it's not the only part of the architecture when it comes to deploying an app on AWS.

I would like to know if you have recommendations when it comes to operating Postgres, how do you deploy your dev and staging environments.

I'm now reaching the point where testing locally requires to many containers for the different services and does not cover real cases that I need to test before shipping to my users.

All recommendations are welcome, with a few exceptions such as: do not deploy on AWS or deploy to something else than AWS as this is a requirement I cannot move around.

Thanks for your understanding and support and do not push to production on Friday ;-)

Do I better ignore it for a while until I need it or do I better learn and use it as soon as possible?

edit: I'll stick with the basics. thank you guys!

I just updated Cal-Invite a headless gem that let you manage calendar invitation. It supports different formats such as: .ics, url, Google, Yahoo and Microsoft.

The full documentation and code is available on the GitHub page.

Feel free to comment and request features if you do not have time to contribute to it.

Happy Friday!

https://github.com/DashAPI-ai/cal-invite

With the recent "migrate everything from rails to rust, don't look at the code, just vibe" trend, and after building a few cli and tools in rust myself (with AI), I felt it was time to learn at least a little bit about Rust... so I vibe coded a course.

It might have incorrect content, as I don't know shit about rust and I'm trusting AI 100% here, so I made it open source so anyone can contribute.

Live course: https://rust-for-rails.pages.dev/
Github: https://github.com/silva96/rust-for-rails

Two years ago I started a project management app in Rails. I thought about React for the frontend, but it looked like too much work for one person: a second app, an API, a build pipeline. So I went with Hotwire: Turbo, Stimulus and ViewComponent.

Today the app has about 150k lines, 711 ERB templates and 194 Stimulus controllers, and no React at all.

Honest summary: it worked out. But some things were fiddly. The typical case: you change the title of a ticket in the detail view. Now the list next to it has to update, and maybe the list is sorted by title, so the row has to move. The header shows the title too. And the sidebar has a list of "recently edited tickets". One change, four places on the page.
With Turbo Streams I update each place by hand, and every new place is one more thing to forget. In React this is just state, and everything that uses it renders again.

I also code a bit in React, so I know the other side. More than once I asked myself if I should move some parts to React after all. But is the additional work worth it?

Then I saw the Herb talk from RubyConf. What impressed me: I saw almost everything I know from React again, and it looks much better than I expected. It seems that they really thought of everything. My first thought was: if this works, I will never need React in this app.

But maybe I am too optimistic, and others know it better. So my questions:

1. For the "one change, many places" problem: is Herb (with ReActionView) the answer, or is Turbo 8 page refresh with morphing already the answer and I just did not use it?

2. Is Herb ready for an existing app with hundreds of ERB templates, or is it better for a new one?

3. Where would you still use React in a Rails app today?

If you want to see what a Hotwire-only app of this size looks like, it is open source since this month: https://github.com/lalabase/lalabase

New On Rails episode with Hussain Akram and Antonio Carlos de Souza from Donorbox.

They’ve got roughly 50 engineers working around a mostly-monolithic Rails app, so we dug into how they’ve kept things relatively boring while scaling.

We get into:

• when something actually deserves to leave the monolith
• running Rails at scale on Heroku
• moving CI from CircleCI back to developers’ machines
• migrating from Slim back to ERB
• Rails conventions and onboarding
• where code goes when you don’t have a services/ folder
• how they’re approaching AI-generated code

Lots of pragmatic Rails decisions in this one.

Podcast:
https://podcast.rubyonrails.org/2462975/episodes/19997194-hussain-akram-antonio-carlos-de-souza-rails-scales-for-the-rest-of-us

YouTube:
https://www.youtube.com/watch?v=3Y42uiA4tdE

✌️

Problem I hit: for apps with health or personal data, the exception message is the riskiest part of an error report, because we put the failing value in it. But error trackers group occurrences by message, so you can't just drop it.

What I ended up doing: normalize the message in-process (hex addresses, UUIDs and digit runs replaced), SHA-256 it, keep the first 32 hex chars, and send that instead of the text. "Couldn't find Patient with id=12" and "id=13" group together; different messages stay apart; nothing about the text goes over the wire.

The normalization is a few lines of Ruby:

normalized = message

.gsub(/0x\h{4,}/, "0x")

.gsub(/\b\h{8}-\h{4}-\h{4}-\h{4}-\h{12}\b/, "<uuid>")

.gsub(/\b\d+\b/, "<n>")

Digest::SHA256.hexdigest(normalized)[0, 32]

Raw request paths get similar treatment: a route template like /patients/:id is kept, but an unmatched raw path keeps only its first segment, since anything after it could be a name.

Disclosure: I built this into my error tracking gem (forge_ops_tracker, MIT, source at https://github.com/Luke-Popwell/forge-ops-tracker-ruby) as a strict privacy mode. Longer write-up with the tradeoffs: https://getforgeops.net/guides/error-reports-without-personal-data

Curious whether anyone handles this differently, e.g. structured error codes instead of messages, or filtering in an exception notifier before it leaves.

We're starting a new series of blog posts dedicated to the engineering part of rubyonrails.org/ai .

Leaderboards, insights, token and dollars spent are great for picking your next model but when it's time to design evals for your product, framework, or software factory, it's good to know where to start and what to expect.

In this first post, we're sharing our experience of writing black-box (e2e, browser-based) tests. The post also includes the results for running cross-stack evals for Rails and Rust.

I spent some time digging into why one of my test suites was so slow. The agents had picked up lots of small bad habits: creating records in setup, replaying state machines just to get a record into the right state, turning off transactions, testing private methods, and freezing the clock in tests that didn't care what time it was. A lot of these are blind alleys that I would not have gone down but have seen junior devs do in the past.

Here's some of the learnings:

• - No DB writes in setup or before the 1st assertion, use fixtures.
• - Never set use_transactional_tests = false, not even for thread or race tests. Rails shares the test's connection with spawned threads, so they see the same data.
• - Never test private methods or call them with send, they are either branches of some public method and you should test them through the public methods that call them or they should be public.
• - Only assert a callback is registered, never create records just to fire it, test it in isolation
• - Split jobs into a selection query and a public per-record method or separate job, and pass fixtures to that method in tests.
• - Only use travel_to/freeze_time in tests that assert on time or need to move it.
• - Parse big files (API specs, schemas) once per run and make them available in a global helper, not once per test.
• - Stub subprocesses, never shell out in tests.
• - Fix N+1s with preloads, never turn off strict loading.
• - Only run tests with bin/rails test, locally and in CI, with file or line filters. No new test flags, env vars, runners or test DBs. Don't invent new ways to run the suite.
• - No comments, write coherent readable code that conveys its purpose inherently.
• - Prove the gain: compare wall time against main, back to back, in one process.

This isn't everything. It's just what I found in one codebase, and yours probably has its own. Start with your slowest test files and look for whatever keeps showing up.

When a fix gives you a real saving, have your agent write a RuboCop rule for it and run it in CI to prevent the same drift from recurring.

Curious what other patterns people have hit.