Squidex: a headless CMS where the API is the product

The problem Squidex solves, and who ends up using it

A traditional CMS bundles content storage with a rendering layer. The README draws the contrast directly: "In contrast to a traditional CMS Squidex provides a rich API with OData filter and Swagger definitions. It is up to you to build your UI on top of it." That single sentence defines both the audience and the exclusion. The audience is teams that already have a front end (a website, a native app, or another server) and only need a place to define content types, store entries, and query them. The exclusion is anyone who expects the CMS to produce HTML pages.

Because the API is the interface, the people who touch Squidex day to day are not editors clicking through a theme customiser. They are backend and frontend engineers defining schemas, plus whoever writes the queries that pull entries into the app. Content modelling happens in the admin UI, but consumption happens in code. If your team has no one who wants to write that consumption layer, Squidex is asking you to build the part that other CMS products give away.

The project is written in C# on ASP.NET Core and, according to the README, uses CQRS internally. It is tested for Windows and Linux on modern browsers. That is a .NET shop's tool more than a PHP shop's tool, and the deployment table (Azure, AWS, Docker, GCP, Heroku, IIS, Kubernetes, Render, Vultr) reflects an expectation that you will run it as a service, not drop it into shared hosting.

OData filtering, Swagger definitions and a CQRS backend

The mechanism worth understanding is the query surface. Squidex does not hand you a fixed REST shape per content type and stop there; it exposes OData filtering, which means the client composes the filter rather than the server pre-defining every endpoint. Swagger definitions describe that surface, so client code can be generated rather than hand-written. For a content hub serving several front ends, that is the difference between adding a field and shipping a new endpoint, and adding a field and changing only the query.

Internally the README names CQRS. Command Query Responsibility Segregation means writes and reads travel different paths, which is a common shape for systems that need an audit trail of content changes and independent read scaling. The README does not document the event store or the read-model projection in detail, so treat the CQRS claim as an architectural signal rather than a documented operational guide. What you can verify from the repository layout is that the backend is split into src, tests and extensions directories, and that the Dockerfile builds backend and frontend as separate stages before assembling a runtime image.

The storage layer is deliberately plural. The topics list MongoDB, MySQL, PostgreSQL and SQLServer, and the prerequisites section repeats the same four. That flexibility is real, but it is also the first place where an operator has to make a decision the README does not help with: it lists the engines without comparing them or describing how to move between them.

Installing Squidex with Docker and making a first API call

The README points Docker users at the hosting repository rather than inlining a compose file, and the deployment table links a docker-compose.yml there. The image itself is squidex/squidex on Docker Hub, which the README references through its pull badge. The build configuration uses the SQUIDEX__ prefix, as the Dockerfile shows with SQUIDEX__BUILD__VERSION and SQUIDEX__BUILD__ARGS.

A Docker-based start uses the published image. The README does not inline the runtime environment variables, so the exact store configuration key has to come from docs.squidex.io rather than from this article; treat the command below as the shape of the invocation, not a verified configuration:

docker run squidex/squidex

What you should see is the container starting and the service listening for HTTP. The README does not state the container's port, so check the hosting repository's docker-compose.yml for the published port before wiring up a browser.

For a local build from source, the prerequisites are the .NET 8 SDK, Node.js (development only), and one of the four databases. The repository ships build.ps1 and build.sh at the top level, and the Dockerfile shows the underlying publish command:

dotnet publish src/Squidex/Squidex.csproj --output /build/ --configuration Release -p:version=$SQUIDEX__BUILD__VERSION ${SQUIDEX__BUILD__ARGS}

Once the service is up, the Swagger definitions are the entry point for client work. The README also notes an sdk directory in the repository, and search traffic for a Squidex client library suggests that generated clients are the intended path rather than hand-rolled HTTP calls.

Where Squidex stops being the right tool

The clearest limitation is stated by the project itself. If you want a CMS that renders pages, Squidex is the wrong layer. There is no theme system to fall back on, and the README's framing leaves no ambiguity about who builds the UI.

The second limitation is operational. Squidex is a .NET service with a separate database, and the deployment table lists nine platforms because there is no single blessed way to run it. That is flexibility purchased with responsibility: backups, database upgrades, and the service lifecycle are yours. The README does not document rollback, and it does not describe a migration path between the four supported database engines. Choosing MongoDB at the start is therefore closer to a commitment than the prerequisites list suggests.

The third is documentation maturity. The README says of the docs site, "Read the docs at https://docs.squidex.io/ (work in progress)". A project that describes its own documentation as work in progress is telling you to expect gaps, and the runtime configuration keys are one place where that shows. None of this makes Squidex unsuitable, but it changes the adoption calculus: budget time for reading source and asking on the Discourse forum at support.squidex.io, which the README names as the place for help, feature requests and bugs.

Squidex compared with Strapi

The most common comparison, and one that shows up in search data, is Squidex versus Strapi. The difference is not feature parity; it is runtime and language. Strapi is a Node.js application, so a JavaScript team can read its internals and extend it in the same language as the front end. Squidex is ASP.NET Core with CQRS, so extending it means writing C#, and the repository's extensions directory is where that happens.

The second difference is the query model. Squidex leans on OData filtering and Swagger definitions as its public contract, which suits clients that want to compose queries at runtime. A team that prefers a fixed, hand-written REST surface per content type will find that model more machinery than they asked for.

The third is deployment shape. Squidex explicitly supports MongoDB, PostgreSQL, MySQL and SQLServer, and documents Azure, AWS, GCP, Heroku, IIS, Kubernetes, Render and Vultr as targets. That is a wider infrastructure spread than most Node-based headless CMS projects advertise, and it matters if your organisation already has a database standard. If your standard is Postgres and your team writes TypeScript, the choice is close; if your standard is SQLServer and your team writes C#, Squidex is the shorter path.

Licence, releases and the cost of staying current

Squidex is MIT licensed, which permits commercial use and modification with minimal conditions; the repository ships a LICENSE file at the top level. The README also notes that a SaaS version exists at cloud.squidex.io, so the same codebase is available as a hosted service if you would rather not operate it. That is a commercial option, not a licence restriction, and nothing in the README suggests the open source edition is feature-limited. For legal questions about your own use, consult your own counsel; the MIT text is the authority, not this article.

Upgrade cadence is visible in the release list: 7.22.0 and 7.23.0 landed in April 2026, and 7.24.0 followed on 2026-09-28, the same day as the last push to master. The gap between 7.23.0 and 7.24.0 is roughly five months, so plan for a handful of upgrades a year rather than a constant stream. The repository carries a CHANGELOG.md, which is where the actual breaking-change detail lives; the README does not summarise version-to-version migration steps.

The real upgrade cost is not the application binary, it is the database. Because Squidex supports four engines and the README documents no cross-engine migration, an upgrade that changes schema expectations lands on your database, and your rollback plan is whatever your database tooling provides. Verify that before you upgrade, not after.

Editorial conclusion

Adopt Squidex if you already run MongoDB, PostgreSQL, MySQL or SQLServer and you want content modelling behind an OData and Swagger API that your own front end consumes. Do not adopt it if you need a themed website out of the box, or if nobody on the team is comfortable operating an ASP.NET Core service and its database. Before committing, verify two things against your own environment: that the schema editor covers your content shapes, and that the Docker image or Helm chart runs against your database version, because the README lists four supported engines but does not describe migration between them.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. Squidex/squidex on GitHub