You can just port things to Cloudflare Workers

In January, Scott Cooper decided to use up his remaining AI credits by attempting to port two existing applications to Cloudflare Workers. The goal was to move away from traditional VPS hosting like Fly.io or DigitalOcean and leverage Workers' free tier and edge computing model. The experiment resulted in two functional ports: a TypeScript version of Simon Willison's Datasette and a reimagined version of a Rails app called Sessy.

The Datasette Port: Navigating Python's Ecosystem

Datasette is a mature, plugin-rich Python tool for exploring and publishing data, built by Simon Willison. Its strength lies in its extensive plugin ecosystem and deep integration with Python's data science stack, particularly SQLite. The challenge was that Cloudflare Workers don't natively support Python's runtime or its vast library ecosystem.

Cooper's approach was to use Codex (powered by GPT-5.2) to systematically break down the Datasette repository into manageable tasks. The AI was prompted to create a README with a task list, which Cooper then executed step-by-step. This methodical process was necessary because a direct port was impossible; the project's dependencies, including Willison's own sqlite-utils library, weren't compatible with the Workers environment.

The solution involved a strategic narrowing of scope. Instead of replicating every feature, the port focused on the core functionality: serving data from SQLite databases via an API. Cooper selected a modern TypeScript stack for the Workers environment:

• Drizzle ORM: For database interactions with Cloudflare D1 (SQLite).
• Hono: A lightweight web framework for routing and handling requests.
• Alchemy: A framework for managing Cloudflare deployments.

For the frontend, he chose not to build a separate React SPA. Instead, he used Hono's JSX to render templates similar to Datasette's original Jinja templates, keeping the application monolithic and simpler to deploy.

The result, datasette-ts, is a functional port that runs on Cloudflare Workers. A live demo is available at datasette-legislators.ep.workers.dev. The source code is published on GitHub at scttcper/datasette-ts. Cooper is candid about the code's state, noting it's functional but not yet polished.

The Sessy Port: Rebuilding a Rails App for the Edge

The second project was a port of Sessy, a Ruby on Rails application designed to handle email bounces and complaints via Amazon SES (Simple Email Service) and SNS (Simple Notification Service). The motivation was practical: Cooper's own project, xmplaylist.com, sends emails through SES and needed a way to process these notifications.

The barrier was psychological and technical. "I can't get myself to think about Ruby for more than 1 minute," Cooper wrote. The solution, again, was AI-assisted porting. He pointed Codex at the original Sessy repository and several Cloudflare/Hono example repos to create a new monorepo.

This project proved more complex than the Datasette port. The AI initially generated a significant amount of frontend code, including custom select components that were "generally pretty ugly." Cooper had to intervene, instructing the AI to replace these with standardized UI components from shadcn/ui and baseui. This highlights a common challenge in AI-assisted development: the model's tendency to generate verbose or suboptimal code without clear constraints.

Technical hurdles specific to Cloudflare Workers emerged:

1. Asset Routing Conflict: The AI initially placed the webhook endpoint at /webhook. However, since the Worker was bound to /api, Cloudflare attempted to serve /webhook as a static asset, causing a 404 error. This required understanding how Workers' routing rules interact with asset serving.
2. Testing Complexity: Getting tests to run 100% correctly in the Workers environment was difficult, a common pain point when moving from traditional server testing to edge computing.

Despite these issues, the port, named SESnoop, successfully handles the flow of SNS notifications into Cloudflare D1. The source code is available at scttcper/sesnoop. Cooper attempted to publish it as an npm package (datasette-ts@latest) to simplify deployment via Alchemy, though this feature is still in early stages.

The AI-Assisted Development Workflow

Cooper's experience offers a snapshot of modern AI-assisted coding. He used Codex with GPT-5.2 on high/medium settings, running it for approximately one week per project under a team plan. The AI was the "main driver 95% of the time," but human oversight was critical for scoping, code quality, and debugging Cloudflare-specific issues.

The workflow wasn't without friction. The AI's initial outputs were often too broad or misaligned with platform constraints. Success required:

• Precise Scoping: Narrowing the project's goals to what was feasible on Workers.
• Iterative Correction: Fixing AI-generated code that violated platform rules (like the routing conflict).
• UI Standardization: Overriding the AI's aesthetic choices with established component libraries.

Conclusion: Vibeporting as a Viable Strategy

Cooper concludes that porting applications to Cloudflare Workers is not only possible but practical with AI assistance—a process he might call "vibeporting." The key takeaway is that while the platform has limits (notably, no native Python runtime), its edge computing model and generous free tier make it an attractive target for migrating certain types of applications, especially those that can be re-architected in TypeScript.

The projects demonstrate that the primary challenges are no longer just about writing code, but about managing scope, understanding platform-specific constraints, and guiding AI tools to produce clean, deployable results. For developers with existing applications on traditional servers, the path to the edge may now be paved with AI-generated pull requests.