Arx OS

The software and AI layer powering Deilliant's product platform. This monorepo houses all microservices and the Infrastructure as Code (IaC) to provision and manage cloud resources — designed to avoid vendor lock-in and remain portable across cloud providers.

Repository Structure

arx-os/
├── services/
│   ├── <service-name>/
│   │   ├── Dockerfile
│   │   ├── .ci/
│   │   │   └── pipeline.yaml     # CI/CD config (provider-specific)
│   │   ├── src/
│   │   └── README.md
│   └── ...
├── infra/
│   ├── modules/                  # Reusable, provider-agnostic Terraform modules
│   ├── gcp/                      # GCP-specific root configurations
│   ├── aws/                      # AWS-specific root configurations (future)
│   └── README.md
├── shared/                       # Shared libraries and types
└── README.md

Each service is self-contained: its own Dockerfile, CI/CD pipeline config, and service-level README.md documenting its purpose, API surface, and environment variables.

The infra/ directory uses Terraform with a modules-first approach — provider-specific root configs consume shared modules, so the core infrastructure logic is not tightly coupled to any one cloud.

Services

Service	Description	Status
contact-service	REST API for client and lead Firestore databases	Active

Tech Stack

• Primary Cloud: Google Cloud Platform (GCP) — current default, not a hard dependency
• IaC: Terraform (modules-first, provider-agnostic)
• Containers: Docker — all services are containerized for portability
• CI/CD: Provider CI (Cloud Build on GCP); pipeline configs live per-service under .ci/
• Orchestration: Cloud Run / GKE (GCP); equivalent targets on other providers use the same Docker images

Getting Started

Prerequisites

• Docker
• Terraform >= 1.5
• Cloud provider CLI for your target environment (e.g., gcloud for GCP)
• Appropriate IAM / credentials for your target cloud

Running a Service Locally

cd services/<service-name>
docker build -t <service-name> .
docker run --env-file .env -p 8080:8080 <service-name>

Provisioning Infrastructure

cd infra/gcp          # or infra/aws, etc.
terraform init
terraform plan
terraform apply

Deploying a Service

Deployments are triggered manually from your local machine — there is no automated CI on push.

Deploy a single service to GCP:

gcloud builds submit --config services/<service-name>/.ci/pipeline.yaml

Deploy all services:

for service in services/*/; do
  gcloud builds submit --config "${service}.ci/pipeline.yaml"
done

Branch Strategy

Branch	Purpose
main	Active development. Merge feature work here.
prod	Production-ready code. Merge from main when ready to ship, then run the deploy.

Shipping a new version:

1. Merge your changes into main and verify locally
2. Merge main → prod
3. Push prod to origin
4. Run gcloud builds submit from your machine to deploy

No GitHub Actions. No automated triggers. Deploys are intentional and manual.

Conventions

• One service per folder under services/
• Each service owns its Dockerfile and CI/CD config under .ci/
• Shared code lives in shared/ and is versioned independently
• All infrastructure lives in infra/ — no cloud config is buried in service code
• Terraform modules in infra/modules/ must be provider-agnostic; provider-specific logic belongs in the provider root (infra/gcp/, infra/aws/, etc.)
• Secrets are never committed — use your cloud provider's secret manager (e.g., GCP Secret Manager, AWS Secrets Manager)
• terraform.tfvars files are gitignored; copy from terraform.tfvars.example and fill in locally