Skip to main content
A target is a generator. It takes an App Definition and produces something that runs.
dotnet-vue is the first-party one: ASP.NET Core, EF Core, PostgreSQL, Vue 3 and Vuetify. What it produces serves three faces from one process. The application itself, a REST API documented at /scalar from a real OpenAPI 3.1 document at /openapi/v1.json, and an MCP endpoint at /mcp. All three go through the same permissions.

​
Every target declares both halves

A target reports what it supports and, separately, what it deliberately withholds. Those aren’t the same thing, and neither one is the third case: a construct the target has never heard of.
​
it builds
The target generates this.
​
it will not build, and says why
The target knows this construct and has a reason for not generating it. The reason is part of the declaration, so the answer you get is “not this, because…” rather than silence.
​
never heard of it
A different answer, and worth not blurring with the one above. It usually means a typo or a construct newer than the target.
Capabilities are declared per concern: blocks, effects, triggers, field types, platform targets and platform entities, plus whether the target can do windowed rollups and series or prev() references. The clearest example of Withheld is the pair of cross-app triggers. A standalone build is one application, and one application has nobody to subscribe to, so command.emitted and process.state_entered are withheld with exactly that reason rather than left looking unfinished:

​
Asking about one app and one target

Without --target this is an ordinary validity check. With one, it also answers whether that generator can build this app, and lists anything it can’t.

​
Missing behaviour is loud

If the app uses something the target can’t generate, this refuses. It won’t quietly hand you an application with a workflow missing, because an app that looks finished and isn’t is worse than a build that failed.
--allow-incomplete accepts it anyway and prints exactly what got left out. Right flag while you’re still building, wrong flag for a release.

​
The generated project is yours

The output depends on no service of ours. No license server, no account, no model API. It’s an ordinary ASP.NET Core and Vue project, and it keeps working whether or not this project does. It has one library dependency on us, Cordango.Standalone, restored from NuGet like any other package. That one is Apache-2.0 and its source is public, so it can be read, forked or replaced, and --runtime source removes even the dependency.
​
flag
Emit Cordango.Standalone as source into the project instead of referencing the package.
​
number
A different deterministic demo dataset.
Platform features need a Cordango workspace. Sign up here and create one in a few minutes.

​
One definition, two destinations

The same App Definition runs on the Cordango Platform and generates a standalone application. What each supports is where they differ. The standalone target builds one application: its own backend, frontend, database, users, authentication and permissions. Not multi-tenant, no AI at runtime. Cordango Platform runs many applications as one company system: shared people and organizations across apps, cross-app references, audit history, governance, AI, search and managed hosting. There is one thing the standalone target does that the platform cannot. A generated application is compiled, so it can carry custom code of your own: a function a formula calls, or a hook that runs on write. The platform interprets a definition and has no compiler, so an application carrying custom code is refused rather than published with the figures it cannot work out left blank. Neither one drops something it can’t do without telling you.