> ## Documentation Index
> Fetch the complete documentation index at: https://docs.credibledata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Environment Overview

> Understand environments — the stable, governed foundation for your data

An **environment** is a container within your organization for the two building blocks of a governed data experience:

* **Packages** — versioned semantic models, plus the reports, dashboards, and data apps built on them.
* **Connections** — secure, managed links to the databases and warehouses those packages read from.

Environments are **stable, governed resource configurations**. They change deliberately — through modeling and publishing — and are the foundation your team analyzes *against*, not where analysis happens. Analysis happens in [workspaces](/how-to/analyzing/workspaces), which consume the models an environment publishes.

## Where an Environment Fits

```
Organization
├── Environment: analytics
│   ├── Connections          → secure links to your databases
│   │   └── warehouse (→ snowflake.com)
│   └── Packages             → published semantic models + apps
│       └── sales-model
│           ├── v1.2.3       (versions)
│           └── v1.2.4 (latest)
└── Workspaces               → where analysis happens
    └── consume published packages
```

Two properties do most of the work:

* **Connections are shared.** Configure a data source once and every package in the environment can use it. Credible indexes each connection's schema so AI agents can discover tables and suggest models. See [Connect a Database](/how-to/modeling/connect-data).
* **Packages are versioned.** Every publish creates a new immutable version. Pin one as **latest**, or publish unpinned to test before promoting. See [Publishing](/how-to/modeling/publishing).

## Common Patterns

Teams typically organize environments around a **department** (finance, HR, RevOps — each owning its own data and models), around **delivery stages** (dev, staging, production, plus private per-developer sandboxes), or a **hybrid** of the two. See [Environments & Packages Best Practices](/platform-admin/environments-packages) for these patterns in detail.

## Your Credentials Stay Secure

An admin stores database credentials in the environment once; no one needs to handle them again:

* **No local credentials.** Developers and modelers SSO into Credible and use the environment's managed connections — nothing is stored on their machines.
* **All access is proxied.** Every request to the underlying data — from an IDE, the in-app agent, a workspace, or an API — goes through Credible, never directly to your database.
* **Access-controlled and audit-logged.** Every request is checked against the environment's ACLs and recorded in an audit log.

This makes Credible a secure perimeter around your data — grant analysts, partners, or applications governed access to your models without ever exposing a credential.

## Environment Roles

Grant access to an environment with one of three roles, assigned to users or groups. A role applies to every package in the environment; you can also grant narrower access on an individual package.

| Role        | What they can do                                                                                                                                                        |
| ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Admin**   | Full control — manage connections, packages, and sharing, and grant access to others.                                                                                   |
| **Modeler** | Build and publish packages. Modelers can list and use the environment's connections, but cannot see or update connection configurations — credentials stay with admins. |
| **Viewer**  | Read and query published packages (for example via workspaces or the [MCP tools](/how-to/analyzing/ai-assistants-mcp)), without modeling access.                        |

For the full permission model — organization roles, groups, and package-level sharing — see [Users & Groups](/platform-admin/groups-permissions).

## Environments vs. Workspaces

<CardGroup cols={2}>
  <Card title="Environment" icon="cube">
    The **stable foundation**. Holds governed packages and connections. Changes
    through deliberate modeling and publishing. Managed by admins and modelers.
  </Card>

  <Card title="Workspace" icon="browser">
    Where **work happens**. Team members chat with data, build reports and data
    apps, and explore & iterate on published models. Consumes what environments
    serve. See the [Credible App](/how-to/analyzing/workspaces).
  </Card>
</CardGroup>

## Next Steps

First connect your data, then pick how you want to build:

<CardGroup cols={3}>
  <Card title="Connect a Database" icon="database" color="#628698" href="/how-to/modeling/connect-data">
    Add a managed connection to your environment
  </Card>

  <Card title="Build in the App" icon="sparkles" color="#628698" href="/how-to/modeling/in-app-development">
    Build models with the agent in your browser — no setup
  </Card>

  <Card title="Local Development" icon="laptop-code" color="#628698" href="/how-to/modeling/local-development">
    Build in your IDE with your preferred coding agent
  </Card>
</CardGroup>