Product model changes

Conceptual map from legacy Projects to Applications, Environments, Services; URLs, shared compute, mixed state.

Written By Zoro

Last updated 3 days ago

Legacy Project → current entities

This page summarises product model changes around legacy Projects and the current Application → Environment → Service model. It complements Migrate from legacy Projects to Applications, which covers what to do in the UI and during operator-led bulk migration.

Legacy Project → current entities

Project as the main bucket for services → Application: The Application is the product boundary: name, default Environment, settings.

Project “server” / hosting target → Environment compute: Compute (Worker Node or managed compute) attaches to an Environment, not loosely to a grab bag of services.

Services on a project → Services under an Environment: Same runnable units (app, database, docker, …), but scoped to an Environment after migration.

Implicit or informal stages → Named Environments: Use explicit Environments (for example production, staging) instead of overloading one project.

Navigation and primary hub

  • New default: Work flows through Applications in the sidebar and URLs.
  • Legacy Projects hub remains reachable for unmigrated work; access may require the legacy dashboard query or bookmark; see the migration task guide.
  • Expect team members to see different menus depending on whether they live in Applications or still open the legacy Projects list.

Migration semantics (what the server records)

  • An Application is created or updated, with migratedFromProjectId linking back to the source project when a new app is created.
  • Shared compute: If another Environment in your tenant already uses the same compute binding, migration may reuse that Environment instead of creating a parallel one.
  • The legacy Project gets migratedToEnvironment, is soft-deleted, and disappears from the default legacy listing.
  • Services gain environment (and tenant scoping as required). Internal project references may remain until a follow-up normalisation migration runs on the database; see docs/normalize-service-ownership-migration.md in the repo for operators.

URLs and redirects

  • Legacy /project/[projectId] paths redirect to the Application that absorbed the project, not necessarily to a specific Service page.
  • Update runbooks and bookmarks that assumed stable legacy project/service paths.

Mixed state during rollout

  • New Applications and legacy Projects can coexist in the same Organisation.
  • Do not assume every teammate sees the same entry point: align on Application URLs for new work and document how to reach the legacy Projects hub when needed.

See also