Hosting event ticketing software with a coding agent

Who this page is for

Chobble Tickets is event ticketing software. It lists an organiser's events, sells tickets to them, takes the payment through Stripe, Square or SumUp, and checks attendees in at the door.

Most pages on this site are written for the organisers running those events. This one is written for people who use a coding agent, such as Claude Code, to set up and change the software they run.

Organisers who would rather not deal with code can use managed hosting instead. Nothing on this page is needed to sell tickets on a hosted site.

The whole product is readable

Chobble Tickets is published under AGPL-3.0-only with no proprietary parts and no paid feature tier. That licence lets anyone read, change and run the software. Where a modified version is offered to users over a network, it requires that those users be offered its source. The licence text states the terms.

An agent reading the repository is reading the same code that runs on managed hosting.

That matters more for an agent than for a person. An agent asked to change behaviour that lives in a closed component cannot see what it is changing, and will guess.

Checks that run before a change can merge

The usual limit on letting an agent change software is that nobody can tell whether the change was any good without reading it. Chobble Tickets answers part of that question mechanically. Each check below either passes or names the file and line where it failed.

Two further tools run against chosen modules rather than the whole repository. Mutation testing changes operators in the source and reports any mutation the tests failed to notice. A test quality audit flags assertion patterns that pass without proving much.

Why the limits sit where they do

A complexity ceiling and a line ceiling stop a function growing past the point where the next reader, human or otherwise, can hold it in mind. An agent that keeps adding branches is told to stop while the function is still small enough to restructure.

The duplication rule has a larger effect than its size suggests. Copying an existing block and adjusting it is the least effortful thing an agent can do, and at a 0% threshold it fails. The repository's guidance is to merge the two into one helper rather than edit around the check.

The codebase therefore tends towards one way of doing each thing, which is worth more to whoever reads it next than to whoever wrote the rule.

What the checks do not claim

Much of Chobble Tickets is written by coding agents, and parts of it are rough. That is true of most repositories past a certain size, and none of these checks claims the code is better than a person would have written.

What they change is when the work gets reviewed. The project's development shell installs a git pre-commit hook that runs the typecheck, lint, duplication, build and test steps, so an agent meets them at commit time, and the same checks run again before a merge.

An agent working that way goes through rounds of revision it would otherwise skip by stopping at its first attempt. The hook can be bypassed, and continuous integration is the backstop when it is, but the ordinary path puts those revisions before anyone reads the change.

The change a person then reads is shorter and closer to the project's conventions. The effort moves to the agent, which can run these checks repeatedly, and away from the reviewer, who would have to find the same problems by reading.

Conventions the checks cannot enforce

AGENTS.md states the rest for an agent to follow. It sets out seven test quality standards, including that tests call production functions rather than reimplementing them, and that they test behaviour rather than implementation detail.

It also requires that errors are never suppressed, sets out the functional patterns the codebase uses, and describes how user-facing copy should read, with before and after examples.

One runtime, one file

Chobble Tickets runs on Deno, and the repository pins the version. The production runtime, Bunny Edge Scripting, is Deno-based too, so code that runs in development runs at the edge.

The build compiles the application to a single JavaScript file. A benchmark recorded on 14 July 2026 measured the self-contained build at 5.51MB, and a production build is smaller because it publishes the shared browser assets to a CDN rather than inlining them.

An edge script is not running while nobody is using it, so a request can arrive with nothing warm. The same benchmark loaded that 5.51MB file in about 156 milliseconds and served its first request in under 3 milliseconds. A whole ticketing application at that size is the reason those numbers are small.

Pages are rendered on the server from TSX templates, using a JSX runtime written inside the repository rather than React. There is no separate front-end application to build and deploy alongside the server.

No server to maintain

An edge script has no operating system to patch, no container to rebuild and no instance to keep running. The database is a managed Bunny database, and its schema migrates itself on the first request.

For an agent helping somebody else deploy, that removes the part of the job that usually takes longest to explain. There is no virtual private server to provision, no reverse proxy, no TLS renewal and no SSH, so the work runs through a Bunny dashboard and a GitHub Actions workflow. Deploying an event ticketing site lists the steps.

Docker deployments are also supported, against local SQLite or a remote libSQL database. Those do leave a host to maintain, for as long as the site runs.

References

• Chobble Tickets on GitHub - source, AGENTS.md and deployment steps
• Technical documentation - generated module and configuration reference
• Deno - the runtime the product is built on
• Bunny Edge Scripting - the serverless platform used for the recommended deployment
• Deploying an event ticketing site - what setting a site up involves