Projects, environments, and resource boundaries

Ethen exposes a project-oriented route family, including project pages for Gateway, logs, policies, usage, sandboxes, and workflows. That navigation model is useful for scoping product activity, but it does not establish durable ownership, environment separation, tenant isolation, or promotion workflows.

The sections below explain the project boundary and the backend and governance work required before it can serve as an enterprise isolation unit.

Projects

A project groups related configuration and product activity. Routes such as /projects/[projectId]/gateway, /projects/[projectId]/logs, /projects/[projectId]/policies, and /projects/[projectId]/usage indicate intended project scoping.

The dynamic identifier should be treated as a lookup key, not proof of authorization. Server routes must verify that the authenticated identity is allowed to access the requested project. Do not fabricate project IDs in product links or examples.

Project persistence, membership, archival, deletion, and organization ownership remain under review.

Project readiness checklist

Before a project holds sensitive or production work, verify the project record is durable, the owner can be identified from trusted server state, membership changes are enforced, and project-scoped routes query only that project’s resources.

Review each subroute separately. Gateway configuration, logs, policies, usage, sandboxes, and workflows can use different stores and authorization paths. One correctly scoped page does not prove that the entire route family is isolated.

Document project closure behavior before onboarding regulated or contractually restricted data. Archival and deletion are not established simply because a project list exists.

Project identifier handling

Treat the dynamic project identifier as untrusted input until the server validates ownership. Do not use a client-supplied project ID as the sole filter for privileged queries or provider configuration. Derive the caller from the trusted authentication context and verify the relationship before reading or changing the project.

Log safe correlation identifiers for denied cross-project attempts without exposing the target project’s data.

Creation and naming

Project creation should establish a stable identifier and owner before product-specific configuration is added. Names are labels for people; authorization should use the stable server-side identifier.

Avoid putting customer secrets or regulated data into project names because names can appear in navigation, logs, or support screenshots. Project naming, archival, and transfer policies are incomplete.

Project identifiers can appear in logs, traces, and support records. Treat them as correlation data rather than secrets, while avoiding unnecessary exposure of customer names or sensitive project labels.

Environments

Development, staging, and production environment controls are not established as an Ethen product feature. A deployment can have separate infrastructure environments, but the documentation must not imply built-in environment creation, variables, promotion, or policy inheritance.

If the organization operates several deployments, document which identity provider, Supabase project, credentials, providers, and data stores belong to each one. Avoid sharing production secrets with development environments.

Environment labels should describe actual infrastructure rather than a UI assumption.

Separate deployments without inventing a product feature

An organization can operate development and production deployments using its hosting, Supabase, provider, and secret configuration. That is an infrastructure practice, not a verified Ethen environment-management product.

Keep separate identity settings, Supabase projects, provider keys, storage, and observability destinations. Label the deployment clearly in operational records and avoid copying production customer data into development.

If configuration must move between deployments, export only non-secret values through an approved process and recreate secrets in the destination. No built-in environment promotion is documented.

Provider accounts and model entitlements can differ between deployments even when the Ethen source revision is identical. Validate the actual provider route, allowed model, and budget in each environment. A configuration that succeeds in development should not be promoted on the assumption that production has the same account access.

Resource scope

Resources can include provider credentials, models, policies, logs, usage events, runs, workflows, assets, and evaluations. A resource is project scoped only when the route and backing store enforce that ownership.

Review the identifier carried from the request into the server query. Confirm that a client cannot substitute another project ID and receive data. Service-role access requires particular care because it can bypass ordinary RLS when used incorrectly.

Shared external provider accounts may cross project boundaries even when Ethen records are separated. Document that dependency.

Scope matrix

A resource can be shared intentionally, but the shared boundary should be explicit and approved.

A shared resource should identify its sharing rule. For example, a provider credential may be deployment wide while usage records remain project scoped. That arrangement can be valid, but cost attribution and incident response need to account for the shared provider boundary.

Do not label a resource “project isolated” when one of its critical dependencies is shared and untracked.

When a resource has no reliable project owner, classify it as deployment shared or unresolved rather than assigning ownership from its route location. That label gives administrators a clear signal that cost, access, and deletion require additional review.

Isolation

Complete tenant isolation is not verified. Isolation can depend on application authorization, database RLS, storage bucket rules, provider-account separation, local runtime configuration, and infrastructure deployment.

A route hierarchy does not create isolation by itself. Neither does a migration prove that all production policies were applied correctly.

For sensitive workloads, test cross-project access and inspect the resulting server and database behavior. Keep the isolation-unverified flag until ownership and enforcement are demonstrated in the deployed environment.

Cross-project test

Use two authorized test identities or API contexts and two non-sensitive projects. Attempt to read and modify each project through the page and server routes. Verify that identifiers cannot be substituted, list queries do not return both projects, and service-role operations apply an explicit owner filter.

Inspect logs and observability for leakage as well. A correctly denied data query can still write a log containing another project’s name or identifier.

Repeat the test after migrations, RLS changes, identity-provider changes, and new project subroutes. Isolation is an ongoing property of the deployed system, not a one-time conclusion from code structure.

Isolation testing should include write paths as well as reads. A user might be unable to view another project yet still submit a run, policy, or provider configuration under its identifier. Check create, update, delete, and action routes for the same ownership enforcement.

Shared infrastructure boundary

Two projects can share an application deployment, database service, provider account, or observability backend while remaining logically separated. That design increases the importance of trusted owner filters, RLS, scoped credentials, and careful logs.

Where the required isolation cannot be demonstrated, use separate infrastructure for sensitive workloads rather than relying on route naming.

Promotion

No built-in promotion workflow is documented for moving projects, policies, workflows, or provider configuration between environments. Do not invent staging-to-production approvals, configuration packages, or rollback behavior.

Where promotion is needed, define the exported configuration, secret-handling method, reviewer, validation steps, and rollback outside the product. Never copy production credentials into a lower environment as part of that process.

A manual process can support operations, but it should remain clearly separate from implemented Ethen capability.

Manual change package

Where a controlled deployment change is needed, prepare a package containing non-secret configuration, source revision, migration plan, policy changes, provider requirements, validation steps, rollback steps, and approving owner. Recreate secrets through the destination’s approved secret process.

Apply and verify one environment at a time. Record actual outcomes rather than assuming development behavior will match production provider entitlements or backend state.

This process is external operational guidance. It must not be described as an Ethen promotion feature.

A rollback should restore both code and configuration. If a provider key, policy, or migration changed, reverting only the application revision may not restore the earlier state. Capture those dependencies in the manual package.

Governance

Project governance should identify the owner, permitted users, approved providers, policy scope, usage budget, data classification, and closure procedure. Those controls may reside across several systems until the organization model is resolved.

Review project access when staff, purpose, provider, or data sensitivity changes. Project deletion should not be described as complete unless related records, local copies, providers, logs, and backups have been considered.

The project model remains a useful navigation and scoping concept, not an approved guarantee of enterprise tenancy.

Project ownership record

Maintain a project record with owner, business purpose, data class, users, provider accounts, key policies, budget owner, storage locations, and closure requirements. The record can live outside Ethen until the administration model is durable.

Ownership should be reviewed when the project changes purpose, adds a provider, begins processing sensitive data, or moves between deployments. A project without an accountable owner should not receive broader credentials or production access.

Governance cannot create isolation that the server and store do not enforce; it should drive the tests and remediation that establish that boundary.

When a project closes, revoke credentials that were dedicated to it, remove user access, address external provider data, and record the disposition of logs and artifacts. No universal project-deletion workflow is verified, so closure should remain a controlled administrative process.

Review shared resources explicitly during project transfer. A provider credential or local runtime may remain controlled by the former owner even when the project record changes.

A project review should also confirm that closed or transferred work is removed from dashboards, usage views, and approval queues where the product supports those updates. A stale visible record can mislead operators even when direct access has been removed.