Project Overview

What Is a Project?

A project is the central organizational unit in the Skytells Console. It is the parent boundary that groups every resource belonging to the same product, service, or environment: apps, databases, domains, environment variables, team members, monitoring, and integrations.

If the Console is your control plane, then a project is the operational estate you manage within it. All workloads that should run together, communicate internally, and share a deployment and access context belong inside the same project.

Architecture

Every project creates an isolated operational boundary. When you deploy an app or provision a database inside a project, it is reachable on the internet by default — Skytells provisions a public endpoint through the reverse proxy automatically. You can disable public access on any service at any time to make it internal-only.

Alongside this, every project comes with a private internal network that all services share from day one. Services within the same project discover and communicate with each other by service name — no IP configuration, no credentials, no public routing needed for internal calls. This means an app can serve public traffic while simultaneously communicating privately with its sibling services over the internal network.

Each App is a single, independently deployable container — a web service, an API, a background worker, or a scheduled job. Each Database is a managed container scoped to the project. All of them share the same private internal network and are reachable from each other using their service name as a hostname, regardless of whether they are also exposed to the internet.

What a Project Contains

Enterprise by Design

Skytells projects are not lightweight containers. They are built to be the long-term control boundary for serious workloads.

• Access governance — team membership and roles are managed at the project level, not by sharing credentials across services.
• Private networking — every app and database inside a project shares an internal network. Services communicate by service name without touching the public internet. Public access can be disabled per service. See Enterprise Network.
• Shared operational context — monitoring, usage, and logging are unified across all project resources so operators can reason about the project as a single system.
• Inherited configuration — project-level environment variables, integrations, and deployment context are available to all apps in the project without manual duplication.

Environment Variables

Environment variables can be defined at two levels inside a project:

Project-level — values shared across all apps in the project. Ideal for secrets or configuration that multiple services consume, such as a shared API key or a database connection string injected by Skytells automatically. Manage them at Project > Environment Variables.

App-level — values scoped to a single app. These override or extend project-level variables for that specific service. Manage them from the individual app's settings.

Project Settings

Project-level settings cover the configuration and lifecycle of the project itself:

• Name — rename the project at any time. The change propagates across the Console immediately.
• Defaults — review project-wide configuration defaults that apply to all child resources.
• Danger zone — high-impact operations such as archival or deletion, when available in the Console.

Access project settings from Project > Settings.

Monitoring and Usage

Every project has a unified observability layer:

• Monitoring — aggregated health, metrics, and logs across all apps. Use it to correlate issues across services within the same project before drilling into individual app logs.
• Usage — a breakdown of resource consumption and cost for the entire project. Compare projects by spend or identify which workloads are driving resource pressure.

For deeper observability across all projects, see Cognition in the Console overview.

Team Members

Team access is managed at the project level. Invite collaborators by email and assign them the appropriate role. Members gain access only to the resources inside that project — not to other projects on the account.

To invite someone, open Project > Members and follow the invite flow.

When to Use One Project vs. Many

Use a single project when:

• The apps and databases belong to the same product and need to communicate internally.
• They should share the same team, operational visibility, and deployment context.
• You want environment variables and integrations to be available across all services without duplication.

Create a separate project when:

• The workload is unrelated to an existing project.
• The access model or team boundary should be distinct.
• The environment should be isolated (for example, separating production from staging).

Next Steps