Atlas is a dedicated AI development server used as the primary Linux host for source code, automation, development tooling, operational scripts, and future application deployment work.

This repository is the authoritative infrastructure and operations source for Atlas. Its long-term purpose is to make the server rebuildable from a clean Ubuntu installation using documented, version-controlled, idempotent automation.

Current Server Summary

The following facts are established for the current server:

Hostname: atlas
Operating system: Ubuntu 26.04 LTS
Static IP address: 192.168.10.10
CPU: AMD Ryzen 7 2700
Memory: 16 GB RAM
OS storage: SSD using full-disk LVM, mounted at /
SQL data volume: SSD mounted at /sql
Development volume: SSD mounted at /srv
Repository location: /srv/repos/AI-Development-Server
Git remote: git@git.catherinelynwood.com:atlas-bot/AI-Development-Server.git

Do not add unverified server details to this repository. Use TODO: Confirm during the relevant implementation phase. where information is not yet established.

Repository Purpose

This repository will contain:

Atlas architecture and operating documentation.
Server standards for scripts, services, configuration, deployment, and change control.
Installation automation.
Configuration templates.
Operational scripts.
Smoke tests and validation checks.
Recovery and rebuild runbooks.
Architecture Decision Records.
Build history.

It must not contain secrets, passwords, tokens, private keys, live credentials, database backups, generated deployment artefacts, or local machine state.

Design Principles

Git is the source of truth for infrastructure and operational intent.
Changes should be documented before they are automated.
Installation scripts must be idempotent and safe to rerun.
Manual server changes should be reduced over time and recorded when they occur.
Source, build artefacts, deployed applications, data, backups, and temporary files must remain separate.
Secrets must live outside the repository.
Planned components must not be documented as installed until verified.

Repository Layout

.
├── README.md
├── SERVER-STANDARDS.md
├── docs/
│   ├── ARCHITECTURE.md
│   ├── BUILD-LOG.md
│   ├── REBUILD-GUIDE.md
│   ├── DISASTER-RECOVERY.md
│   ├── OPERATING-MODEL.md
│   └── adr/
├── install/
├── config/
├── scripts/
├── tests/
├── templates/
└── .gitignore

Directory-level README files explain what belongs in each working area.

Future Installation Model

Future installation scripts will live under install/. They will be ordered, idempotent Bash scripts, for example:

install/01-base-tools.sh
install/02-dotnet.sh
install/03-sqlserver.sh
install/04-nginx.sh
install/05-docker.sh

These scripts do not exist yet. Until they do, rebuild steps remain manual and are documented in docs/REBUILD-GUIDE.md.

Change Control

Plan architecture and standards changes before implementation.
Review diffs before committing.
Run relevant validation before commit.
Do not commit without explicit approval.
Keep commits focused on one infrastructure outcome.
Record meaningful operational changes in docs/BUILD-LOG.md.

Roadmap Summary

Phase 1: Establish repository structure, standards, architecture documentation, rebuild guidance, disaster recovery guidance, operating model, and ADR process.
Future phases: Add idempotent installation scripts, configuration templates, operational scripts, smoke tests, backup automation, restore automation, deployment automation, and monitoring.

Security Warning

Never commit secrets or credentials. This includes .env files, passwords, tokens, private keys, certificates, SQL backups, Codex authentication material, deployment credentials, and backup encryption keys.

Use templates, examples, placeholder names, and documented environment variable names instead.

Rebuild and Recovery

Rebuild procedure: docs/REBUILD-GUIDE.md
Disaster recovery: docs/DISASTER-RECOVERY.md