Who this is for. Everyone new to Core dna, whatever they will build. By the end of this page you will know what the platform runs for you, which parts of it you work with, and why there is no local copy of the application to set up.
A hosted, multi-tenant platform
Core dna is one application serving many customers at once. Core dna hosts it, runs it and upgrades it. Nobody building a site installs it, runs it on a laptop or deploys it.
- One codebase for every site. Every customer site runs on the same platform code, so when the platform is upgraded, every site has the upgrade.
- One database per customer. Each customer, called a client, has its own database. A client can have several sites, and their content, layouts, users and settings all live in that client's database.
- The hostname decides which site answers. Every request is matched by its hostname to one environment of one site, and through it to the client and its database. Hostname to site, prefix to abstraction follows that step in detail.
There is no local version to run. You work against a development environment that Core dna hosts for the site: you change files in the site's repository, deploy them, and load the page from the development hostname. Deploying a change shows how a change gets there.
What you work with
| Part | Where | What it is for |
|---|---|---|
| The admin | /cdna-admin | Content and its structure: pages and other records, layouts, input types, menus, forms, users, settings, jobs and media |
| The theme repository | A git repository for the site | The site's templates and front-end assets, and nothing else. Pushing a branch deploys it to the environments that follow that branch |
| The REST API | /cdna-api/… | Reading and writing every kind of record, one entity type per request |
| The GraphQL API | POST /cdna-api/graphql | Reading several entity types in one request |
| Custom endpoints | /cdna-api/webhook/<slug> | Endpoints you define in the admin as jobs, without platform code |
| The MCP server | /cdna-mcp | An AI assistant in your editor reads and changes the site's content and structure, acting as you |
All of them answer on the site's own hostname, and all of them read and write the same data. The URL surfaces of a site shows a real request to each.
What you do not get
- The platform's source. The application, with its modules, its admin and its APIs, is not in your repository and you cannot change it. When a site needs something the platform does not do, that is a request to Core dna, not a change to the theme.
- A server to look after. There is no web server, database or PHP version for you to configure.
- A build on the server. Nothing is compiled when you deploy. The CSS and JavaScript a site serves are the built files you commit: The build output is committed and served.
What this means day to day
- Changes are made in two places. Templates and assets change in the repository and arrive with a deploy. Everything else, layouts and content included, changes in an environment's admin or through the API, and a git push never carries it. What is yours and what is the platform's draws the line.
- The platform's interfaces are your contract. You build against the variables a template receives, the methods on each record, the API's routes and the admin. These guides document them, and the generated Reference lists every model, route and default template.
- Development starts in the admin. A template does nothing until a layout points at it, so a new kind of page begins with a layout: Development starts with a layout.