> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cordango.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Deploying a generated app

> Running what cordango build produces.

```bash theme={null}
cordango build --app support --target dotnet-vue --out ./out
```

What lands in `./out` is an ordinary ASP.NET Core, EF Core, PostgreSQL, Vue 3 and Vuetify project.
No license server, no account, no model API, no runtime dependency on Cordango. It keeps working
whether or not this project does.

## Run it

```bash theme={null}
cd out
docker compose up
```

The scaffold ships its own `docker-compose.yml` with the database alongside the application.

## The first screen creates the administrator

There is no default password, and no password printed to a log. A password delivered by a log line
is not delivered: it sits in a scrollback, a log aggregator and a CI artifact, and nobody ever
rotates it.

Instead the first screen asks you to create the account. Once that has happened, the endpoint that
creates it **closes for good**.

<Warning>
  Reach the application before anyone else does. Between first start and first account, that endpoint
  is open to whoever gets there. On a laptop this is nothing. On a public address, start it closed to
  the world and open it once you have signed in.
</Warning>

## The key ring lives on the volume

Data protection keys must persist. If they live inside the container, every restart invalidates
every existing session and every token signed with them.

The generated compose file puts them on a volume. Keep that arrangement when you move to whatever
you actually deploy on, and back that volume up with the database rather than separately from it.

## Migrations

The generated project includes an EF Core migration for the schema its definition describes. It is
certified: regenerating it produces an empty diff, so what is in the project is exactly what the
model implies.

When you change the app and regenerate, you get a new migration. Review it like any other, because
a generated migration is still a migration and it still runs against real data.

## Choosing how the runtime arrives

<ParamField path="default" type="source">
  `Cordango.Standalone` is emitted as source into the project. Nothing to restore, no feed to
  depend on. This is what makes the output independent.
</ParamField>

<ParamField path="--runtime package" type="NuGet reference">
  References `Cordango.Standalone` from a feed instead, pinned to the generator's version. A smaller
  repository, at the cost of a dependency.
</ParamField>

Pick source unless you have a reason. The whole argument for the standalone target is that what you
generate outlives its generator.

## Seed data

```bash theme={null}
cordango build --app support --target dotnet-vue --out ./out --seed 7
```

Deterministic demo data. The same seed produces the same dataset, which makes it useful for a demo
environment and for a screenshot that has to look the same next week.

It is demo data. Do not ship it to production and do not build a report against it.

<Note>
  **Platform features are currently in invite-only beta.**
  [Sign up here](https://www.cordango.com/beta/) to be considered for one of our next phases.
</Note>

## Publishing to the Platform instead

Generating is one of two destinations. The other is an instance:

```bash theme={null}
cordango publish --app support
```

Same definition, different target. See [Publishing](/cli/publish).