Atlas projects & sources
A project is where Atlas docs land and how often they refresh. You add one or more sources to it; each source becomes its own folder of generated pages.
Create a project
A project takes:
| Field | Choices |
|---|---|
| Name | The project's name — also names its output folder. |
| Owner | You, or an org you administer. |
| Output space | An existing space, or a new one created for the project. |
| Cadence | hourly / daily / weekly / monthly. |
| Auto-update | On or off. |
Where the pages land
When a project outputs to a space, Atlas creates a folder named after the project, and each source publishes under its own sub-folder. The tree reads:
Space → [optional top-dir] → Project → Source → pages
[!NOTE] If you create a brand-new space named after the project, that space is itself the namespace — Atlas adds no extra project folder inside it.
Each per-source folder is kind-tagged so a multi-source project stays scannable:
"<source> - repo"for a git source"<source> - jira"for a Jira source
Add a git source
| Field | Notes |
|---|---|
| Repository URL | e.g. https://github.com/owner/repo. |
| Branch | Optional — clones this branch only. |
| Subpath | Optional — ingest only files under this path. |
| Include / exclude globs | Optional — narrow what's ingested. Comma-separated; supports * (within a path segment) and ** (across segments). |
| Credential | Optional — required for private repos. |
Atlas uses git ls-files to enumerate tracked files, so .gitignore is honoured for free. Binary files and empty files are skipped. Test files — paths under test/, __tests__/, e2e/, fixtures/, testdata/, and filenames matching *_test.go, test_*.py, *.test.ts, *.spec.ts, and similar patterns — are kept for retrieval and citation context, but are excluded from the surface inventory.
Languages with surface extraction (routes, functions, types, env vars, etc.):
| Language | Method | What's extracted |
|---|---|---|
| Go | AST (accurate) | Exported functions, exported types, HTTP routes, entry points (main()), CLI flags (flag.*), env vars (os.Getenv), outbound HTTP calls, structs with db:/gorm: tags |
| Python | Regex | HTTP routes (Flask/FastAPI decorators), classes, top-level functions, env vars, CLI options (argparse/click), outbound HTTP (requests/httpx), ORM models (Django/SQLAlchemy) |
| Java | Regex | Spring route mappings, public classes/interfaces/enums/records, main(), env vars (System.getenv, @Value), outbound HTTP clients, @Entity and Repository interfaces |
| JavaScript / TypeScript | Regex (shared pack) | Express/router routes, exported functions/classes/consts, process.env.*, outbound (fetch/axios) |
| SQL | Regex | CREATE TABLE statements |
All other recognised file types — Ruby, Rust, Shell, Markdown, YAML, JSON, HTML, CSS, and more — are ingested and embedded for retrieval and citations, but don't contribute surface items.
The must-cover surface (entry points, HTTP routes, CLI flags, env vars, data models) is what the [[Atlas runs, coverage & freshness|coverage report]] holds to 100%. Everything else — exported types, outbound calls, etc. — is tracked but not required.
Add a Jira source
| Field | Value |
|---|---|
| Location | The Jira base URL (e.g. https://your-org.atlassian.net). |
| Subpath | The project KEY (e.g. COM). |
| Credential | A jira credential — required. |
When a Jira source runs, Atlas fetches the entire project over the Jira REST API and materialises three inputs before generation:
- One
.mdfile per issue (e.g.COM-123.md) — title, status, assignee, description, and comments. schema.md— the project's structure: issue types, components, statuses, custom fields, versions, and epics.status.md— a current-state snapshot: how many issues are in each status, epic completion percentages, and what's blocked or in-flight.
The must-cover surface for a Jira source is the project schema — every issue type, component, status, custom field, version, and epic must be addressed in the docs. The per-status counts and per-epic progress in the status snapshot are also tracked surface items.
The source's ref is the RFC3339 timestamp of the most-recently-updated issue. Delta runs detect changes via a small JQL count query — no full re-fetch — and only re-ingest issues updated after that timestamp.
[!IMPORTANT] Atlas authenticates to Jira using HTTP Basic auth (
email:token). The API token must have read access to the project's issues, schema, and custom fields. A project-scoped or instance-level read-only token is sufficient; no write access is needed.
Binding a credential
When you bind a credential to a source, the picker offers credentials owned by the project's owner, plus your own personal credentials. A personal credential on an org project is flagged "personal — private to you" — see [[Atlas credentials]] for what that means.
Deleting a project
Deleting a project removes the project configuration and all its sources and run history. The output space and generated pages are left in place — you won't lose the docs, only the ability to regenerate or update them. Delete the space separately if you want to remove the pages too.
Related
- [[Atlas credentials]] — what a credential is and who can see it.
- [[Atlas runs, coverage & freshness]] — what happens when a source runs.