This post is part of our Curling IO v3 sneak peek series, where we explore some of the new features available in the upcoming version.

Clubs often need to send purchase information to systems outside Curling IO. That might mean updating a spreadsheet, notifying staff, or starting a workflow in another service.

Rentals are one example. Someone may need to prepare the lounge, reserve tables, arrange catering, or add the booking to a staff spreadsheet.

Curling IO v3 webhooks can send that product purchase to Zapier, n8n, or another HTTPS endpoint when it is submitted, paid, cancelled, or rescheduled.

This post is part of our Curling IO v3 sneak peek series, where we explore some of the new features available in the upcoming version.

Curling IO v3 includes a new draw scheduling screen for event games. The schedule is a grid of draws and club resources, with unassigned games kept in a queue beside it. You can drag and drop games, lock specific placements, and use Allocate and Optimize around those locks.

Unlike a separate schedule template generator, this editor works with the event's actual teams, stages, games, resources, and draw times. Saving the schedule updates the event directly.

You can try most of the scheduling interface now at CurlingSchedules.com. It uses generic teams and browser-local saves instead of an event's actual games, but the grid, drag-and-drop editing, locks, catalog schedules, fairness inspection, and optimization are available today.

This post is part of our Curling IO v3 sneak peek series, where we explore some of the new features available in the upcoming version.

Curling clubs use rentals for practice ice, lounges, meeting rooms, and other bookable resources they define. A rental needs a product and price, but it also needs a schedule, one or more resources, public availability, and a booking record after checkout.

In Curling IO v3, an administrator defines the rental schedule and resources in the admin area. Available time slots appear on the public calendar, where curlers can add one to the cart and complete checkout. This post explains the rental options being added and how they fit into the calendar.

This post is part of our Curling IO v3 sneak peek series, where we explore some of the new features available in the upcoming version.

Membership associations sometimes need more than a recommended waiver. A group insurance policy may require every member club to present the same approved language to its Participants.

Emailing a Word document to each club distributes the wording, but it does not keep that wording under control. A club can edit its copy, miss the next update, or keep collecting responses against an old version. Later, the association may have no reliable way to tell which document a Participant actually saw.

Curling IO v3 will connect those pieces. A membership association can publish one locked waiver, make it available to its member clubs, update it in one place, and report on which clubs have Participants responding to it.

Curling IO used to run on Debian configured with Ansible. That setup worked. It installed packages, configured Caddy and the firewall, created systemd services, and prepared our blue-green deployment slots.

The problem was not that Ansible couldn't describe the server. The problem was that a working, mutable server let us get away with an incomplete description. Old files remained under /etc. Build tools had been installed through a different path. Provider choices about disks and RAID lived outside the playbook. A provisioning run could succeed because an earlier run had already left the right thing behind.

NixOS is much less tolerant of these gaps. This strictness is occasionally annoying, but it is also the main benefit. It forces us to decide who owns a file, a service, a secret, a package, or a recovery input.

Moving from Ansible to NixOS taught us how much validation and cleanup the old approach had been missing. It exposed the difference between a server that continues to work and one we can recreate from declared inputs.

This is what we found useful while rebuilding an OVH bare-metal server from empty disks, restoring its state, and making the process safe enough to repeat.

This post is part of our Curling IO v3 sneak peek series, where we explore some of the new features available in the upcoming version.

Curling clubs sell much more than leagues and bonspiels. They run clinics, rent ice, assign lockers, host junior camps, sell banquet tables, and collect donations.

Today, each of those offerings has to fit one of Curling IO's predefined types. That works, but sometimes only because a club picks the closest available bucket. One active junior summer camp is stored as a Product, with its August dates written into the name. A full-sheet ice rental is stored as a Program because it needs a date, capacity, and a waitlist. A donation is stored as a Fee.

In Curling IO v3, the organization decides which product types it needs. A club can create Camps, Clinics, Ice Rentals, Locker Rentals, Fundraising, or any other category that fits its operation, then choose what each type can do.

We know that many of our clubs use WordPress or Joomla for their curling websites. These are popular platforms, and for good reason: they're flexible and there's no shortage of tutorials and plugins. But that popularity comes with a serious downside. General-purpose CMS platforms are big targets, and volunteer-run clubs often don't have anyone watching the security queue. Here's what you need to know.

Imagine you're a club manager setting up next season. You open your AI agent and type (or just say):

Set up early bird pricing for the Tuesday Night League. 15% off if they register before September 1st.

Five seconds later, it's done. No browser tabs, no forms, no clicking through menus. With Curling IO v3, this is something you'll be able to do.

This post is part of our Curling IO v3 sneak peek series, where we explore some of the new features available in the upcoming version.

Registration forms in Curling IO have always collected the basics: team name, lineup, skill level, contact info. But every club runs things a little differently. Some need emergency contacts. Others want dietary restrictions for banquet planning. A bonspiel might ask for team contact information while a league doesn't.

In v2, admins can already choose which questions appear and create custom ones. What's new in v3 is control over the layout: where each question sits, how wide it is, and how the form is organized into sections.

Curling IO's admin panel should feel instant when a club manager is working through a season setup. Toggle a setting, save a discount, move between product sections: the page should respond without a full reload.

Version 2 works, but every form submission reloads the page. Version 3's admin is a single Lustre server component running on the BEAM. One WebSocket connection, one long-lived Erlang process per session. Every interaction goes over that WebSocket and comes back as a DOM patch. The page never reloads, and there's no client-side JavaScript framework.