Developer ships marketyour.games, a web app written in C and served via CGI

The essay opens with a historical contrast. In 1994 a dynamic website meant a C program in a cgi-bin directory, forked per request by Apache. Thirty-two years later, the author says, they shipped a commercial web product on fundamentally the same technology. The product is marketyour.games: a web app with user accounts, a search dashboard for content creators, folders for organizing them, payments via Stripe and transactional emails via Postmark. It follows progressive enhancement and does not require any JavaScript. Everything about it is modern, the author says, except how it was made and how it is served.

The central claim is that CGI's decline was justified in 2004 but does not hold up in 2026, and that you can write a modern web application in C. The stack is BCHS: OpenBSD, C, httpd and SQLite. There is no framework (a C program reads CGI environment variables and responds), no templating language (the C code outputs HTML directly), no separate database server (the app opens the SQLite file through its C API) and no container (a statically linked binary goes into a folder). Every request spawns a fresh process, so deploying a new version means replacing one file, with no server restart and no downtime.

The author leans on three additional libraries, of which two are actual build dependencies, libcurl and libsodium, both vendored and built with the project. A clean build takes a few seconds and an incremental rebuild takes less than half a second. Rather than serving static files, httpd routes all traffic to the CGI binary, with every asset compiled into the executable and served from memory. On security, OpenBSD provides pledge and unveil, and httpd serves from a chroot by default, so the CGI binary is sandboxed to its own corner of the filesystem.

The author's arguments for the approach run along several lines. CGI is not a framework to learn: the 1.1 specification was published in 2004 and has not changed since, and anyone who understands HTTP already understands it. The usual setup of nginx reverse-proxying to an application server in Ruby, Python, Go or Rust always felt strange to the author, since it gives you two web servers and one of them also runs the business logic; CGI gives a single web server that calls the logic directly. Debugging is simpler because the application is an ordinary program you can run from a shell, pipe a request into, watch on stderr and step through with gdb. The author likens CGI to serverless architecture, "minus the vendor (and surprise bills)".

Supply chain is another argument. With autonomous agents on the rise and weekly attacks on package repositories, the author finds few dependencies reassuring. Package-manager stacks balloon, with one or two direct dependencies pulling in hundreds of indirect ones. The author's supply chain is a C compiler and three libraries, and compromising it would mean compromising libcurl, a project the whole internet watches.

On tooling, the author uses classic Vim with zero plugins: no LSP, no autocomplete, no code formatters and no AI. The application is a directory of C files and a Makefile. When tooling is wanted, sanitizers, valgrind, gdb, ctags and cscope are mature and a package install away, and Vim has native ctags and cscope support plus a graphical gdb frontend (Termdebug). The author was hesitant to write the whole frontend in C but found it not nearly as painful as imagined: "It isn't pretty, but neither is Tailwind." SQLite replaces Postgres, which the author had always defaulted to, and removes the server process to babysit and the frequent upgrades.

The author is candid about the cost. CGI is only an interface between a web server and the application, so you get very little out of the box and must write your own utilities. The author rolled their own in a single header file, cgi.h, but is not convinced that was the right solution. Libraries such as kcgi exist, but adopting one means buying into its API and security model. The author would like to see a set of shared drop-in utilities, like the stb libraries, and says maybe they will publish cgi.h as a start.

The conclusion: most of the reasons CGI was abandoned in the early 2000s no longer hold. Process forking is not nearly as expensive as it was because modern kernels optimize it heavily, and if forking cost ever became an issue, FastCGI is a simple enough upgrade. The author calls marketyour.games a commercial product running on a single binary, says it has fewer moving parts than anything they have shipped before, and plans to reach for this stack again.

Key facts

marketyour.games, a commercial web product with accounts, a search dashboard, Stripe payments and Postmark emails, is written entirely in C and served via CGI.
The stack is BCHS (OpenBSD, C, httpd, SQLite); the product is one binary plus a SQLite file, with three libraries, two of them build dependencies (libcurl and libsodium, both vendored).
A clean build takes a few seconds and a rebuild less than half a second; deploying means replacing one file with no restart or downtime.
The author argues CGI's decline was justified in 2004 but does not hold up in 2026, because process forking is much cheaper on modern kernels and FastCGI is a fallback.
The main cost is that CGI gives almost nothing out of the box: the author wrote their own utilities in a single header file, cgi.h, and is not sure that was the right call.

Why it matters

It is a working counterexample to the default way of building a web product. Most modern stacks put nginx in front of an application server written in another language and pull in a package ecosystem. Here the author ships a product with accounts, payments and email on a CGI binary, a SQLite file and three libraries, and argues the old objections to CGI have expired. The author also frames the choice as a response to dependency sprawl and attacks on package repositories. This is a tech and engineering story, not an AI one.

Who it affects

Mainly developers who build and run their own web products and are weighing how many dependencies and how much infrastructure they really need. People who already work on OpenBSD or in C have the most direct use for it. The essay does not claim anything for teams with large codebases or traffic; it describes one product built by one author.

How to use it

The essay amounts to a recipe. Run OpenBSD with httpd and route all requests to a single CGI binary. Write the application in C, reading CGI environment variables and printing HTML directly. Open the SQLite database through its C API. Build a statically linked binary with a Makefile and compile assets into it so they are served from memory. Vendor any libraries, as the author does with libcurl and libsodium. Use pledge, unveil and httpd's default chroot to sandbox the program. Ship by replacing the binary file. Expect to write your own CGI helpers, or look at libraries such as kcgi.

How solid is it

It is a first-person account by an author who is not named in the source text, describing one shipped product. The claims about build time, simple deployment and low complexity are the author's own description and are plausible for the stack as described. The source gives no traffic, user, revenue or customer figures for marketyour.games, and no benchmarks of request latency, throughput or fork cost; the argument that forking is cheap is qualitative. No security audit or penetration test is mentioned.

Risks and caveats

The author lists the main downside themselves: with CGI you get very little out of the box and must write your own utilities, and their own cgi.h may not be the right solution. Adopting a library like kcgi means buying into its API and security model. The sandboxing story leans on OpenBSD features (pledge, unveil, httpd's chroot), and the author notes OpenBSD gives the tools to actually secure a C program, which implies that the security work falls on the developer. The FastCGI fallback for fork cost is a hypothetical the author did not need. The 'no AI' remark describes the author's editor setup, not the product.

“CGI is serverless, minus the vendor (and surprise bills).”

— the author