Skip to content

Server Systems

Infrastructure automation for Epic environments — the scripts and runbooks Sapphire Health uses to stand up, refresh, and maintain client server systems.

This site documents the sapphire/ toolkit and the client-specific configurations built on top of it. If you're looking for a script that already exists, start in Tooling overview below. If you're new to the repo, start with the guide.

Tooling overview

The shared toolkit lives under sapphire/bash/ and sapphire/python/. Everything here is built to be packaged as a versioned installer (build_install_script.ps1) and dropped onto a client server.

Area What it does
epic/ Epic dataset expansion — growing production/reporting datasets ahead of time
aws-sup-refresh/ Refreshes a client's SUP (support) environment from production snapshots
aws-create-volumes / aws-attach-volumes / aws-detach-volumes / aws-convert-volumes EBS volume lifecycle for a refresh: create, attach, detach, convert
aws-refresh-snapshots / aws-snapshots / aws-check-snapshot-progress Snapshot creation and progress polling
aws-disk-management General EBS disk operations outside a refresh workflow
aws-sns SNS notifications for automation run status
azure-refresh-disks Azure equivalent of the AWS SUP/disk refresh flow
rhel-storage LVM and filesystem operations on RHEL hosts
active-directory AD account and group maintenance
odro See the script's own docs page for scope

Every script that takes flags documents itself with --help, and has a matching <scriptname>.md next to the source with usage, options, and examples — sapphire/bash/aws-sup-refresh/aws-sup-refresh.md is the reference layout other scripts follow. These per-script docs live next to the code, not in this site, so browse them in the repo directly.

Client environments

Client-specific configuration and overrides live in their own top-level folders (for example bozeman/, chop/, nyu/, urmc/, waco/). These build on the shared sapphire/ tooling rather than duplicating it — if you're debugging a client issue, check there first for anything environment-specific before assuming the shared script is at fault.

Two build systems, one docs/ folder

This site renders under both MkDocs and Zensical from the same mkdocs.yml. If you add a page, confirm it renders in whichever tool you're not currently using before you call it done.

Where to start