The Idea
We're building Cylro for organisations that create and manage multiple public-facing websites across clients, brands, and internal teams.
We want websites to be easier to create, organise, publish, and maintain, without every organisation having to assemble its own separate CMS, hosting, domain, media, access, and publishing systems.
We keep the focus deliberately narrow: company websites, landing pages, portfolios, blogs, and content hubs. Cylro isn't a general application-hosting platform, and it isn't a build-anything-with-AI product.
Why This Exists
It started with my own frustration: separate CMS installations, plugins, hosting dashboards, domains, and the same setup work repeated for every new website.
Our first idea was an open-source CMS that organisations could self-host or run as a managed service. Working through it, we found the harder problem was operations rather than the editor: who's allowed to change what, how a change goes live, and how you get back when it shouldn't have.
That turned into one website operations platform for many sites: Spaces, Studio, structured editing, design systems, access boundaries, controlled publishing, and lightweight static delivery. We're reimagining website operations, not claiming to have invented a category.
Inside a Space
Spaces
A Space is your organisation's working environment and ownership boundary: your people, access, websites, teams, and the responsibility for keeping those sites maintained.
Crews and roles
We built Crews for agencies and larger teams with specialised people on different clients. Roles and scoped permissions decide who can view, edit, publish, or manage. We'll settle the exact vocabulary during the alpha.
Studio
The website workspace: settings, page structure, visual design, reusable blocks, content, media, and themes for one site, wired into the operational controls of the wider Space.
Design system
A design layer for components, structural rules, colours, themes, fonts, icons, and brand guidelines. Shared styling applies consistently across a site, or a designer can switch it off when they want direct control.
On top of that, modules add specialised capability only where a site needs it. Turn on the blog module and that website gets an area for writing articles, editing them, adding images, and managing related content. Collections and the modules we add later follow the same principle, because we don't want to end up with an unstructured plugin collection. Settings, domains, SEO, forms, client-facing access, and analytics are things we're still shaping.
Publishing and Recovery
Build it in Studio
You put a website together in Studio, then our backend runs the build and publishing workflow for it.
Publish as static output
We export the result as HTML and static assets into object storage, where a custom domain, and CDN delivery, can serve it to your visitors.
Keep a way back
We're making publishing versioned, so you can go back to a previous published version, restore it, or take a website offline.
These are controls you trigger yourself. We don't promise automatic rollback, automatic failover, or guaranteed recovery times.
My Role
I co-founded Cylro with Jim and I'm its technical lead and CTO. I set the technical direction and work hands-on across backend architecture, infrastructure, deployment, security, data flow, service boundaries, and how we design the AI integration.
Jim leads the visual, frontend, and product-vision side. We share the product decisions, the company administration, and the business direction, and we run the whole thing as a two-founder team.
Company Timeline
We start Cylro
Jim and I start Cylro in Luxembourg, moving from an open-source CMS idea to one platform for website operations.
Landing page live, product in build
cylro.com is public and people can request early access, while we keep building the platform itself.
Private alpha
We're targeting a private alpha for around November 2026, if we're ready, to see how deployment, updates, failures, recovery, and the gaps in the product hold up in real conditions.
Current Status
Cylro is pre-release and we're still building it. Our landing page is live and you can request early access through cylro.com, but the product isn't open for general use. We're not making any availability, pricing, or service commitments yet.
How I built it
I built Cylro as one multi-website application rather than a collection of isolated site installs. A Space gives websites, people, and access their organisational context; I keep the Nuxt frontend as its own layer; and the Node.js backend is the single controlled path to data, permissions, publishing, and service coordination. We publish the websites themselves as static output, which keeps a live site independent of the application that produced it.
Frontend: Nuxt 4, server-rendered
- A layer of its own: I keep the frontend separate from the backend so it can evolve on its own and stay easier to maintain.
- API-only access: Nuxt talks to the backend through an API. The client never queries the database directly.
Application layer: Node.js and Express
- One controller for the product: I route API communication, data access, authentication, permission checks, rate limiting, publishing, deployment workflows, and service coordination through the backend.
- Rules in one place: I enforce our product rules at the backend boundary instead of re-implementing them per client or per service.
- The path for future AI actions: I'm designing the AI capabilities we plan to act through this same backend, not around it.
Data and caching
- PostgreSQL as our system of record: open source, widely supported, and flexible enough for our structured application data, with JSON where that helps.
- pgvector for where we're heading with AI: I've made room for vector search, contextual retrieval, and semantic lookup. That's direction, not a public feature we've shipped.
- Redis as the caching layer: the backend reads frequently requested and short-lived data from Redis first, which cuts repeated reads against PostgreSQL.
Identity and access
- SuperTokens behind the backend: I chose it over our earlier Keycloak direction because it fit our authentication and backend-connection requirements better. Keycloak is no longer part of the stack.
- Identity isn't the permission model: SuperTokens establishes who someone is. Our backend connects that identity to Spaces, roles, Crews, website scopes, product actions, and publishing rights.
- Room for separate identity contexts: I designed the architecture so we can later handle external website visitors separately from the people operating a Space.
Publishing and delivery
- Static output instead of a container per site: a build produces HTML and static assets, so I don't run a dedicated application container for every customer website.
- Object storage as the origin: we store the published output in S3-compatible storage and point a custom domain at it, with CDN delivery for reach and to keep pressure off our application servers.
- Rollback and recovery you trigger yourself: going back to a previous published version, restoring it, or taking a site offline are your actions. We don't promise automatic rollback, automatic failover, or guaranteed recovery times.
- Dynamic behaviour in the browser: client-side JavaScript covers what a static site needs, so we don't have to server-render every page permanently. E-commerce and heavier dynamic cases are future work.
Containers and infrastructure
- Separate services, separate responsibilities: I designed the Nuxt frontend, Node.js backend, PostgreSQL, Redis, the authentication service, and the supporting services as distinct container boundaries.
- Docker for development and delivery images: Compose covers our local development and delivery-image workflows. It isn't what I intend to run in production.
- Hetzner as our first production provider: affordable compute, suitable storage, and good S3 pricing for a company at our stage. We may look at Scaleway, OVH, and other European providers later.
- Deployment platform still being decided: I'm evaluating a visual container-deployment platform for releases, updates, service health, and operational visibility during the alpha. I haven't fixed the final choice or the multi-server approach.
AI orchestration direction
- Assistance, not our identity: optional help with content drafting, SEO suggestions, review, layout ideas, and routine website or access tasks. We're not trying to replace the people running the websites.
- The orchestration model I'm planning: you'd talk to an umbrella agent that understands the request and delegates bounded work to specialised capabilities.
- No unrestricted authority: I'm designing every consequential action to go through the backend, get checked against our product rules and your permissions, be explained back to you, wait for your approval, and only then run.
- We choose the provider, you don't bring your own model: we provide the AI experience, and we can change model and provider on quality, cost, availability, performance, and European hosting options. The orchestration harness isn't finished, and we have no live public AI features.
Security and operational validation
- No direct client access to core services: sensitive product actions go through the backend, where I enforce permissions, product rules, rate limits, authentication checks, publishing, and operational requests.
- Monitoring is still evolving: I'm building an internal operations view to bring service status and operational signals together, alongside the baseline container logs and health the deployment platform gives us.
- What the alpha has to prove: failures, redeployments, restoration paths, backup behaviour, recovery of published site versions, and re-upload and service recovery. Until it has, I'm not claiming uptime, recovery targets, complete monitoring coverage, or production-proven backups.
How we work
- AI-supported, human-reviewed: AI speeds up exploration, implementation, debugging, and code investigation. We keep the product decisions, the technical direction, the review, and the call on what actually enters the product.
- Validated through hands-on local use: I test changes locally by actually operating the product, not only in isolation.
- Branch-based work in GitHub: we keep parallel work separate to reduce conflicts while we build.
- What we don't have yet: a complete CI/CD pipeline, a formal staging environment, and comprehensive automated testing. Those are what I want to strengthen as the alpha forces real release discipline on us.
What I'm Working On
Core product
Getting Spaces, Crews, Studio, the design layer, modules, publishing, and recovery to work as one coherent system rather than separate features.
Deployment and operations
Settling the deployment platform, the operations view, and the backup and restoration paths I want the alpha to put under real pressure.
Private alpha
Preparing a small, closely supported alpha for around November 2026, and being clear about what's ready before anyone starts.