Skip to content

Latest commit

 

History

526 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Atlaso

Atlaso — Everything your virtualization lab needs

Everything your virtualization lab needs.

Atlaso is an all-in-one infrastructure appliance for virtualization proof-of-concept, lab, and test environments. It brings infrastructure, storage, identity, networking, and lifecycle workflows into one operator-focused control plane.

What Atlaso brings together

  • Infrastructure — deploy and operate a Photon OS appliance across supported virtualization platforms.
  • Storage — provide lab storage and manage VCF depot and backup workflows.
  • Identity — manage local users, LDAP, OpenID Connect, certificates, and scoped credentials.
  • Networking — configure interfaces, default-off routing, NAT with explicit ingress, WAN simulation, DNS, DHCP, firewall policy, public services, and network boot through reviewed desired state.
  • Lifecycle — review desired-state changes, automate tasks, monitor health, and install signed updates.

Appliance Update follows one durable task through service restarts and recovery, with automatic browser status navigation and a final result backed by active-release and service checks.

Successful main CI automatically publishes the immutable wheel handoff, creates the signed software Release, and advances development. Promotion to preview or stable and all OVA/virtualization production remain explicit manual operations.

Start here

  • Documentation — browse the published Atlaso documentation.
  • Getting started — choose an appliance path and complete initial configuration.
  • Operate — manage daily appliance tasks, changes, updates, and troubleshooting.
  • Services — configure infrastructure, identity, storage, and VCF integrations.
  • Reference — review APIs, image building, interoperability, and technical behavior.
  • Contribute — follow repository, documentation, design, and implementation policies.
  • Project — learn about Atlaso branding, roadmaps, and design history.

Supported appliance targets

Atlaso runs on Photon OS 5.0. VMware Workstation is the canonical image-build, live-test, and documentation target. The validated OVF/OVA supports VMware deployment and is the source artifact for KVM and Proxmox VE imports; Hyper-V uses a portable ZIP converted from that same appliance image. Canonical Workstation builds reserve their temporary static builder address outside VMware DHCP before Packer starts, so concurrent clean worktrees do not reuse one endpoint. Build preflight checks VMware-generated paths against a 240-character budget; choose a shorter -StagingRoot for virtualization prereleases or a shorter canonical -OutputDirectory parent for direct image builds when rejected. Protected release finalization and stable promotion admit exactly one version-derived Hyper-V ZIP; suffix-compatible aliases or additional archives fail before signing or publication. Visible builds repair exact missing Atlaso library registrations before starting Workstation, while full artifact cleanup retains its checked post-network-preflight boundary. Successful builders atomically remove empty Packer lock directories; export retains strict read-only lock checks. Failure cleanup verifies Workstation's shutdown-only VMX rewrite before adopting its stopped file identity; unrelated configuration changes and replacements still preserve the artifacts and reservation for recovery.

Contributor-created VMware lifecycle and acceptance VMs use pull-request-owned identities so validation artifacts remain traceable and cleanup cannot adopt a shared or provisional VM name. Task-owned Photon builders follow the same rule: their exact PR identity owns the Packer VM, output, reservation, provenance, and cleanup scope, while portable product and release names remain PR-independent. Before a pull request exists, the explicit local/test builder and normal test-VM modes derive guarded identities from the clean source commit; protected release paths reject local/test provenance, and acceptance evidence remains PR-numbered. See the VMware Workstation lifecycle testing guide.

Password-backed Windows build and test helpers require standard GIL-enabled x64 CPython 3.14. Until 1Password ships an eligible official wheel, Atlaso verifies one immutable, attested compatibility release from the public mdaneri/onepassword-sdk-python fork by exact URL, filename, size, and SHA-256 before 1Password authorization or VMware activity. The wheel is never checked into Atlaso or published to PyPI. When a restricted build network supplies the credential-free PipGlobalIndex and PipGlobalIndexUrl pair, Atlaso uses that same resolved pair for both the host-side hash-locked 1Password dependency closure and the guest Photon build; partial overrides and silent public-PyPI fallback are rejected.

See Getting started for the first-use path and Portable virtualization artifacts for platform-specific import details.

Safety model

Development appliances keep host-mutating adapters in dry-run mode by default. Operators edit desired state, review the resulting appliance changes, and explicitly submit valid units through the global Appliance Apply workflow.

ESXi Network Boot authorizes against the exact successfully applied configuration, retained in a dedicated encrypted runtime record. Display previews and Apply baselines remain redacted; standalone IP addresses, MAC addresses, and host UUIDs remain visible operational identifiers. Recovery from an incomplete applied snapshot requires a real ESXi PXE Apply followed by a fresh host boot attempt; a dry run does not repair it.

The Boot Service Require console authorization switch is off by default. Apply this policy to let assigned ESXi hosts continue without a console code, or enable it for per-attempt administrator approval. Generated attempt directories remain readable by the boot servers even under the appliance service's restrictive umask.

Project and community

Automated pull-request monitoring uses one four-minute current-task heartbeat as the exclusive routine reconciliation mechanism; contributor tasks may make immediate bounded reads while awake, but must not self-schedule delayed shell status checks alongside that heartbeat. See Contributing for the complete workflow.

The documentation describes the latest supported Atlaso release. Pages marked Roadmap or Historical provide context and do not describe current appliance behavior.

About

Atlaso supports POC, lab, and test environments by simplifying deployment, maintenance, and validation.

Topics

Resources

Code of conduct

Contributing

Security policy

Stars

1 star

Watchers

0 watching

Forks

Releases

Packages

Used by

Contributors

Languages