Apps: creating, configuring and shipping targets

How to create a Quodara app, what each step of the setup wizard asks for, and which delivery targets a single app can ship.

Everything you do in a chat sits on top of this layer, so it is worth ten minutes up front.

Where your apps live

Open Apps. Three tabs across the top:

Tab	What it shows
Mine	Apps you created — status, domain links, deployment history
Collect	Apps you have bookmarked
Board	Traffic, referral channels and load performance for an app

Common app statuses:

Status	Meaning
`Creating`	The repository, domain and database are being provisioned
`Creation failed`	Initialisation failed — click the badge for the reason
`Updating`	Configuration is being applied or the app is redeploying
`Success`	Ready to use

Three ways to create an app

Click + New app at the top left and pick one.

Start from a blank app (recommended)

The fastest route, for "I have an idea but no code yet".

Enter an app name
Pick a platform domain
Choose a production subdomain — the matching test. domain is generated automatically
Click Create

Quodara provisions the repository, domains, database and a default deployment config. Everything else gets written by the agent in a chat.

Start from an open-source project

For "I found a GitHub project and want to make it mine".

Enter an app name
Enter the GitHub repository URL, optionally with a branch or ref
Pick the domain and production subdomain
Click Create and let AI adapt it

Once the app exists, Quodara opens a chat automatically and sends your adaptation request to the agent. Continue from there.

Configure manually

For "I already have a repository, a domain and a database". This goes straight into the setup wizard.

The setup wizard

Existing apps reach the same wizard through Edit in the actions column of the app list.

Step	What it asks for	Required
Basics	App name and description	Yes
Repositories	Repository URL, default branch, access credentials	Yes
Domain	Test and production domains	Yes
Database	A platform-provisioned MySQL instance per environment	No
Service accounts	Built-in accounts injected at deploy time	No
Deployment	Working directory, route prefix, start command, built-in config toggles	No
Android app	Build history and signing key export	Read-only

The Android step is read-only and is hidden entirely while you are creating a new app; it appears once there is a build to look at.

What an app can ship

One app can deliver more than a website:

Web app, admin console or API — the default; bind a domain and it is reachable
Android app — Quodara holds the package name and signing key, and you download the built package

Not sure which target you need? Say so in a chat — the agent will use an interactive card to confirm the target and collect whatever credentials it needs.

How the Android target is added, what preview and publish each produce, and where your users download it: 09-multi-target.md.

Built-in runtime configuration

The deployment step has a set of built-in configs. Switch one on and Quodara injects it per environment, so your code can just read it instead of you provisioning and storing secrets:

App name and domain — the identity and address of the current environment
Database — a MySQL instance isolated per environment
Object storage — the app's own bucket for uploads and generated media
Logs — container log collection, searchable when something breaks
Service accounts — built-in accounts injected at deploy time
Frontend monitoring and APM — required before the Board tab has any data

Common questions

Q: Do I get a working URL right away? A: A blank app runs a test deployment automatically; once the status is Success, the test link in the app list opens. The production URL waits until your first Publish.

Q: Can the default branch be something other than main? A: Yes — change it in the Repositories step, and every later chat branches from the new one.

Q: What happens when I delete an app? A: It is not reversible. The repository, domains and data are all reclaimed, so confirm before you do it.