Skip to main content
An App is a full-stack web application. Each App has its own source repository, development sandbox, secrets, runtime storage (D1, Durable Objects, KV, R2), and production deployment. Apps contain within them all the infrastructure they need, except for secrets.

The App object

When you create or read a App with POST /api/apps or GET /api/apps/{id}, the API returns an App object:

Templates

Every new App starts from a template. If you omit template_id when calling POST /api/apps, Judt uses the default Hello template. To list available templates and their id values, call GET /api/templates:
To start from a template, pass its id as template_id when you create the App:
The template files are copied into /app the first time the sandbox starts.

Slugs, custom domains, and URLs

Every App has a slug that determines its .judt.dev address:
If you do not pass a slug when you create an App, Judt generates a three-word slug such as plucky-teal-tatooine.

Slug rules

A slug must meet these rules:
  • Contain 1 to 48 characters.
  • Use only lowercase ASCII letters (a-z), digits (0-9), and hyphens (-).
  • Start and end with a letter or a digit (^[a-z0-9](?:[a-z0-9-]{0,46}[a-z0-9])?$).
  • Be unique across all Apps on Judt, including soft-deleted Apps.
  • Not use a reserved name: staging, preview, api, www, or local.
If a slug is already taken or reserved, the API returns 409 slug_unavailable.

Rename a slug

You can change an App’s name or slug with PATCH /api/apps/{id}:
Changing slug moves the published App to the new .judt.dev address immediately. The old .judt.dev address stops serving the App and does not redirect to the new address.
You cannot change slug or production while a deployment is in progress (409 deployment_unsettled).

Custom domains

This feature is not supported yet. We’ll be adding support soon.
When a custom domain is configured on an App, the domain field contains that hostname and url returns https://<domain>. The https://<slug>.judt.dev address continues to serve the App alongside the custom domain.

Production status

The production.status field reports the live state of the published App: The production.deployment_id field shows which deployment (dep_...) is currently serving in production.

Delete an App and 30-day retention

To delete an App, send DELETE /api/apps/{id}:
Deleting an App does the following immediately:
  1. Sets deleted_at to the current timestamp.
  2. Unpublishes the production deployment so the App URL stops serving traffic.
  3. Stops and removes the development sandbox.
  4. Rejects any new writes, commands, previews, or deployments with 410 app_deleted.
For 30 days after deletion, you can still inspect the deleted App and its history:
  • GET /api/apps?include_deleted=true lists soft-deleted Apps alongside active Apps.
  • GET /api/apps/{id}, GET /api/apps/{id}/commits, GET /api/apps/{id}/deployments, GET /api/apps/{id}/events, and GET /api/apps/{id}/logs continue to work.
After 30 days, Judt permanently removes the App and its records.

Next steps