Squidex is an open-source headless CMS and content management hub built in C# on ASP.NET Core under the MIT licence, for development teams that model content in a backend service and build their own website, native app, or downstream server on top of its API.
What it is
Squidex is a headless content management system and content hub written in C# on ASP.NET Core, following a CQRS architecture. It lives in the .NET ecosystem and requires the .NET 8 SDK together with MongoDB, PostgreSQL, MySQL, or SQL Server for persistence. Rather than shipping a rendering layer, it exposes content through an API with OData filter syntax and Swagger definitions, leaving the presentation tier to the implementer. The project is tested for Windows and Linux on modern browsers, and its container image is published as squidex/squidex.
The concrete problem it solves is the coupling of content storage to presentation in a traditional CMS. In a traditional system the content model and the delivery mechanism arrive as one package, which pushes teams into whatever templating, hosting, and extension model that product chose. Squidex replaces that arrangement with a managed content backend and a documented API, so a website, a native application, or another server consumes the same content without passing through a vendor's front end. Editors work in the administrative UI while developers build clients against the API.
Key capabilities
- Content delivery over an API with OData filter syntax, so clients query and shape result sets server-side.
- Swagger definitions describing the API, enabling generated clients and interactive exploration.
- CQRS architecture on ASP.NET Core, separating command and query paths in the application core.
- Pluggable persistence across MongoDB, PostgreSQL, MySQL, and SQL Server, chosen at deployment time.
- Published Docker image, squidex/squidex, with a reference docker-compose.yml kept in the Squidex/squidex-hosting repository.
- Documented deployment paths for Azure, AWS, GCP, Docker, Heroku, IIS, Kubernetes, and Render.
- MIT licence, with source in C# and versioned releases on GitHub.
Who uses it and how
- Teams building a website, native app, or another server that consumes content over the API instead of through templates.
- Self-hosters running the squidex/squidex image via Docker Compose or Kubernetes, against their own database instance.
- Organisations already standardised on .NET, running the .NET 8 SDK and their existing SQL Server, PostgreSQL, MySQL, or MongoDB infrastructure.
- Windows-focused shops installing under IIS, and cloud-first teams using the Azure ARM template, the Heroku deploy button, or the Render path.
- Developers filing bugs, requesting features, and getting help through the community forum at support.squidex.io.
Getting started
Quickest path is the Docker Compose file from the Squidex/squidex-hosting repository, or pulling the squidex/squidex image directly, with documented alternatives for Azure, AWS, GCP, Heroku, IIS, Kubernetes, and Render. Building from source requires the .NET 8 SDK, a supported database, and Node.js for development only.
How it compares
No paid products this project replaces are listed in the registry facts, and no comparable tools are named there either. Squidex therefore stands alone in this registry as the sole headless CMS described by these facts.
When to use it — and when not to
A self-hoster must operate a supported database (MongoDB, PostgreSQL, MySQL, or SQL Server), the .NET 8 runtime or a supplied image, and one of the documented hosting platforms; nothing in the facts bundles a database or managed offering. Teams wanting a ready-made front end, a hosted service with a support contract, or finished documentation should look elsewhere, because the project's documentation is explicitly marked work in progress and the README gives little end-user guidance. The MIT licence and the small open issue count favour adoption, but the work of building and maintaining the consuming application stays with the adopting team.
