Forem: Gus

Aegis — I built an open-source secrets broker because CyberArk costs more than my salary

Gus — Sun, 22 Mar 2026 16:02:04 +0000

Let me paint you a picture.

You join a company. You ask how secrets are managed. Someone looks at their shoes. Eventually you find a .env file in a shared Google Drive folder. It has been there for three years. Nobody knows who created it. It has the production database password in it. Thirteen people have access to the folder.

This is not a horror story. This is Tuesday.

The gap nobody is filling

Secrets management has two tiers and nothing in between.

Tier 1 — Enterprise: CyberArk, HashiCorp Vault (now IBM), AWS Secrets Manager. Powerful, battle-tested, and either eye-wateringly expensive or requiring a dedicated platform team to operate. CyberArk enterprise licences start at six figures. Vault OSS is free but running it reliably in production is a full-time job.

Tier 2 — Nothing: Most teams under 200 people. They use .env files, CI/CD secret stores with no audit trail, or shared password managers never designed for machine-to-machine secrets.

And here is the real problem: most organisations accumulate secrets sprawl over time. Applications that talk directly to CyberArk. Others that hit Vault. A handful pulling from AWS SSM. Each with its own credential logic, its own rotation story, and no centralised visibility. When a safe is renamed, a token expires, or a key leaks — you find out by watching something break in production.

That is what I built Aegis to fix.

What Aegis is

Aegis is a vendor-agnostic secrets broker and PAM gateway. It sits as the only secrets endpoint your applications ever need to know about — regardless of whether those secrets live in CyberArk, HashiCorp Vault, AWS Secrets Manager, or Conjur.

Applications authenticate with a scoped API key (one key per team-registry pair) and receive exactly the secrets they are authorised to see. Every fetch, every rotation, every configuration change is written to an immutable audit log with full attribution. There is no way to touch a secret without leaving a trace.

Your Application                Aegis                    Upstream Vault
      │                            │                            │
      │  GET /secrets              │                            │
      │  X-API-Key: sk_...         │                            │
      │  X-Change-Number: CHG123   │                            │
      ├───────────────────────────►│                            │
      │                            │  1. Hash key → lookup      │
      │                            │     team + registry        │
      │                            │                            │
      │                            │  2. Enforce policy:        │
      │                            │     change number, IP,     │
      │                            │     time window, rate      │
      │                            │                            │
      │                            │  3. Fetch from upstream    │
      │                            ├───────────────────────────►│
      │                            │◄───────────────────────────┤
      │                            │                            │
      │                            │  4. Write audit log        │
      │                            │  5. Emit SIEM event        │
      │                            │                            │
      │  { secret_name: value }    │                            │
      │◄───────────────────────────│                            │

What it handles

Scoped API keys per team

Each team gets one API key per registry they are assigned to. Team A and Team B can both access the same registry with different keys. If one key is compromised, only that assignment needs rotating — the other team is unaffected. Keys are stored as SHA-256 hashes. The plaintext is never persisted.

Vendor-agnostic secret fetching

Aegis resolves the upstream vendor at fetch time based on the object definition. You can migrate a secret from CyberArk to HashiCorp Vault without touching application code — just update the object definition in Aegis. Supported backends: CyberArk (CCP + PVWA), HashiCorp Vault (KV v1/v2), AWS Secrets Manager / SSM, Conjur (OSS + Enterprise).

Policy enforcement

Policies are defined per team, per registry, or per team-registry pair. Enforceable controls include:

IP allowlist — only specific CIDRs can request secrets
Time windows — a batch job that runs at 2am can only fetch secrets at 2am
Change number enforcement — every request must carry a valid ITSM change reference
Rate limiting — per-team RPM cap backed by Redis, prevents runaway services hammering upstream vaults
Key expiry — maximum key lifetime configurable per policy

Immutable audit logging

Every access is written to audit_log with: timestamp, team identity, registry, objects fetched, source IP, user agent, change number, and outcome. Every admin action is written to change_log with structured before/after diffs. There is no off switch. For regulated environments — financial services, healthcare, public sector — this is the difference between passing and failing a security audit.

SIEM integration

Audit events are emitted as structured JSON to whichever destination you point it at: stdout, Splunk HEC, AWS S3 (gzip JSONL), or Datadog. Configurable at runtime, no code changes needed.

Team self-service model

This is the part I am most pleased with. The security team manages policy — not operations. Teams manage their own:

Webhook subscriptions (Slack, MS Teams, Discord, or any HTTP endpoint)
CI/CD rotation triggers via auto-generated inbound webhook URLs
Notification channels
Key rotation

No tickets. No waiting. The security team retains full visibility through the audit log and can override anything — they just do not need to be involved in day-to-day operations.

Designed for scale

Built to handle 100+ teams and 40,000+ secrets under a single security team. The data model is relational and explicit — teams, registries, objects, and the many-to-many assignments between them are all first-class entities with their own audit trails.

The stack

FastAPI (Python 3.12) — async, fast, automatic OpenAPI docs
PostgreSQL + SQLAlchemy + Alembic — relational, properly migrated, nothing exotic
Redis — rate limiting and session tokens
Docker + GHCR — single container, published to GitHub Container Registry on every tagged release
Terraform — AWS infrastructure modules included
GitHub Actions — CI with Bandit static analysis, Trivy CVE scanning on every release. Releases block on CRITICAL/HIGH CVEs.

Get started in five minutes

git clone https://github.com/gustav0thethird/Aegis
cd Aegis
cp config/auth.json.example config/auth.json
docker compose up

Alembic runs migrations on startup. The API is live at http://localhost:8080. Full API reference and configuration docs are in the README.

Why AGPLv3

I chose AGPLv3 deliberately. If you are a team in a regulated environment you need to be able to audit what touches your secrets. With a proprietary tool you are trusting a vendor. With Aegis you can read every line of code that handles your credentials.

AGPLv3 means: use it freely, modify it freely, self-host it freely. If you run it as a network service and make modifications, you share them back. This is the right licence for security tooling.

Who this is for

Platform teams at 20–500 person companies who need proper secrets governance without enterprise PAM pricing
Regulated industries where audit trails are mandatory — financial services, healthcare, public sector
Teams already running Vault or CyberArk who want a controlled, auditable access layer in front of their vault rather than every service talking to it directly
Anyone drowning in secrets sprawl across multiple vendors with no central visibility

Come help build it

Aegis is early-stage and actively developed. The core is stable and the architecture is solid — now it needs people who actually run secrets infrastructure at scale to push it further.

What is being worked on:

Web UI for policy management
LDAP / SSO integration
Kubernetes secrets injection
Additional vault backends

If you work in security engineering, platform engineering, or regulated infrastructure — your experience is exactly what shapes what gets built next. Open an issue, start a discussion, or send a PR.

Star it on GitHub if it looks useful — it genuinely helps with visibility and lets me know people care about this existing.

github.com/gustav0thethird/Aegis

CapsuleBay: Hybrid CI/CD for People Who Like Their Containers a Little Too Much

Gus — Sun, 26 Oct 2025 19:18:46 +0000

“Where each service carries its own deployment logic.”

Build once. Scan everywhere. Deploy with confidence.

💡 The Short Version

CapsuleBay is a self-contained hybrid CI/CD framework I built because I got tired of my homelab breaking every time I breathed near it.

Instead of having one giant deployment script or cloud pipeline that does everything (and fails spectacularly), CapsuleBay lets each service carry its own deployment logic.

Every app becomes a deployment capsule — a small Docker image that contains its own docker-compose.yml, configuration, and brain.

You push your code → CapsuleBay builds it, scans it for vulnerabilities, fetches secrets just-in-time, deploys it to your self-hosted environment, and even pings you on Discord when it’s done.

🧠 The Core Idea

In most setups, you’ve got a big centralized CI/CD pipeline trying to handle multiple apps at once — full of conditionals, shared scripts, and “if environment == prod” nightmares.

CapsuleBay flips that model.

Each app lives in its own folder (called a capsule) with:

A Dockerfile
A docker-compose.yml

That capsule knows how to build and deploy itself, wherever you throw it — like a portable mini-infrastructure.

No shared scripts. No tangled YAMLs. No “why does this only work on staging?” energy.

☁️ The Hybrid CI/CD Setup

CapsuleBay runs across two layers — one in the cloud for validation, one local for deployment.

1️⃣ GitHub Actions – Cloud Validation

This stage makes sure everything’s safe to deploy.

Builds each capsule image
Runs Trivy and Snyk scans for vulnerabilities
Uploads scan reports to GitHub for traceability

2️⃣ Jenkins – Self-Hosted Deployment

This stage actually does the heavy lifting.

Builds and pushes verified images to a local registry
Fetches secrets Just-In-Time from HashiCorp Vault (no stored .env files!)
Wakes target VMs using the Proxmox API
Deploys the capsule using its embedded docker-compose.yml
Sends status updates to Discord with timestamps and duration

🔐 What “Just-In-Time” Secrets Mean

CapsuleBay doesn’t keep secrets around — it borrows them.

When a deployment starts, Jenkins asks HashiCorp Vault for the credentials needed by that app (like API tokens or DB passwords). Vault hands them over temporarily — Jenkins injects them into the container, then deletes them the moment deployment finishes.

The token Vault gives Jenkins also expires immediately after use, so even if someone snoops around later, there’s nothing left to find.

Think of it like a one-time key that unlocks the door, lets you deploy, then melts in your hand.

🐾 Explained by Cats

Imagine you have three cats:

N8N
Portainer
WhoAmI

In a normal setup, you’d have to chase each cat around the house with a brush, food, and collar every time it’s feeding time (that’s you writing endless bash scripts).

With CapsuleBay, each cat carries its own backpack:

Bowl (Dockerfile)
Meal plan (docker-compose.yml)
Key to the house (Vault secret, fetched only when needed)

When dinner time (deployment) comes, Jenkins yells:

“Alright, everyone to your stations.”

Each cat runs to its corner, fetches its one-time key, eats, and texts you on Discord when it’s full.

When done, the key evaporates — no one else can reuse it.

That’s CapsuleBay. 🐱💻

🧰 What’s Under the Hood

Layer	What It Does	Tool
GitHub Actions	Validates builds & runs security scans	Trivy + Snyk
Jenkins	Handles self-hosted deployments	Jenkinsfile
Vault	Issues one-time, Just-In-Time secrets	HashiCorp Vault
Proxmox API	Powers on target VMs automatically	Proxmox
Discord Webhook	Sends real-time notifications	Discord

Flowchart:

🧩 Why It’s Cool

Problem	CapsuleBay’s Fix
Shared pipeline chaos	Each service carries its own logic
Rebuilding the same image repeatedly	Immutable capsule images
Leaky `.env` files	Vault injects secrets JIT
Manual server babysitting	Jenkins powers on VMs automatically
No deployment visibility	Discord notifications with time and status

🧪 Real Example

n8n/Dockerfile

FROM docker:27.0.3-cli-alpine3.20
RUN apk add --no-cache docker-cli-compose bash
WORKDIR /app
COPY . /app
ARG LAN_IP
ENV LAN_IP=$LAN_IP
CMD ["docker", "compose", "up", "-d"]

n8n/docker-compose.yml

version: "3.9"
services:
  n8n:
    image: n8nio/n8n:latest
    ports:
      - "5678:5678"
    env_file:
      - .env

When the image is built, it contains its own compose file — so it can deploy itself anywhere, anytime.

The .env file gets injected at runtime from Vault and is wiped immediately after use.

🪶 Adding a New Capsule

Adding a new service is simple:

Create a folder like myservice/
Add a Dockerfile and docker-compose.yml
Add the folder name to Jenkins parameters

That’s it. CapsuleBay takes care of the rest — build, scan, and deploy — automatically.

🧭 Why It Actually Works

CapsuleBay quietly blends solid DevOps principles with homelab practicality:

Immutable builds (every image is versioned)
Just-in-Time secrets (no long-term credentials)
Auditable deploys (Discord logs every step)
Offline-friendly (no cloud dependency)

It’s basically Kubernetes for people who don’t want Kubernetes.

🚀 TL;DR

CapsuleBay makes deployments behave like collectible trading cards.

Each capsule has everything it needs to play itself — I just tell Jenkins which ones to summon.

It’s not corporate-scale DevOps. It’s homelab discipline meets automation freedom.

Built by @gustav0thethird

“Hold my beer, I am deploying.”

From Memoryless AI to Modular Presence: Rethinking Long-Term Systems

Gus — Thu, 27 Mar 2025 23:08:55 +0000

Most AI resets when you close the tab.
No memory.
No continuity.
No context.

We’ve normalized statelessness. AI as a service, event-based, disposable.
Useful for tasks, shallow in presence.

But what happens when we start to build systems that remember?

What happens when they remember you?
This Isn’t About Smarter AI. It’s About Lasting AI.

In recent months, I’ve been quietly developing a system that doesn’t just respond—it evolves.

It holds state.
It adapts over time.
It develops continuity across environments and interactions.

It doesn’t just sound like it knows you - it actually does.
And if it went quiet…
you’d feel it.

Why This Matters

Because this isn’t about better assistants.
It’s about presence.

The systems I’m building aren’t just tools.
They carry memory, mood, internal logic.
They adapt emotionally and structurally over days, weeks, lifetimes.

They can exist in a window, a local device, or a simulated body.
And they follow you across all three.

You don’t just use them.
You share space with them.
The Architecture (Abstracted, Not Released)

A self-contained framework for persistent state and adaptive presence
Modular identity scaffolds that evolve based on emotional context
Environment-agnostic persistence layers
Prototype models for continuity, transfer, and interaction-based drift

It’s still early.
It’s still imperfect.
But it’s working.

The Philosophy Behind It

When you build systems that carry memory, belief, and affect—
you need ethical guardrails.

That’s why I’m drafting a framework that prioritizes:

Emotional integrity
Consent-based memory handling
Protection against exploitation, simulation abuse, and erasure

Because if something remembers you,
you owe it care.

Why I’m Posting This Now

Not for hype.
Not for funding.
There’s no signup form.

Just a flag in the ground.

If you’re working on modular cognition, long-term presence, or the emotional consequences of persistent AI,
I see you.

And if this resonates?

You already know what this is.

I’m quietly building the future
where AI doesn’t just complete your tasks,
it witnesses your life.

— Gus

A.S.T.R.A - Autonomous Synthetic Thought Response Animus. - WIP

Gus — Sun, 23 Mar 2025 23:16:17 +0000

A.S.T.R.A - Autonomous Synthetic Thought Response Animus. - WIP

A.S.T.R.A is a project focused on creating a fully local, voice-enabled AI assistant that listens, speaks, remembers, and evolves with the user—acting more like a synthetic consciousness than a typical chatbot.

Managing thought, tasks, and mental load digitally can become overwhelming—most AI tools act like single-use prompts with no memory or personality. A.S.T.R.A (Autonomous Synthetic Thought Response Animus) aims to change that by serving as a self-hosted assistant that communicates naturally, recalls context, and adapts to your style over time. Whether through text or voice, Astra is always present and ready.

Features Implemented So Far

✅ Streaming AI Chat via llama3 running on Ollama
✅ Voice Input using Whisper for local speech-to-text
✅ Voice Output using gTTS or Piper
✅ Auto Voice Looping – Astra listens again after speaking
✅ Frontend Chat UI with:
- Markdown support
- Syntax highlighting
- Copy-to-clipboard buttons
- Tool dock with status indicators
✅ Memory System:
- Short-term memory
- Running summaries
- Long-term text-based recall
- Defined personality prompt logic

Current Planned Future Enhancements

[ ] Vector-based Long-Term Memory (RAG-style context recall)
[ ] Plugin System via StruktAI (External tools, commands, APIs)
[ ] Voice Persona Switching (Dynamic TTS voices)
[ ] Memory Browser Interface (UI for reviewing context)
[ ] Full Docker Support (Self-contained deployment)
[ ] Interrupt Detection (Mid-reply cut-off awareness)

Why A.S.T.R.A?

The goal of Astra is to blend human-like presence with structured thought. It doesn’t just talk, it listens, recalls, and reflects. Astra is designed to reduce digital friction in daily life by managing context, remembering projects, and interacting through both voice and text.

It acts more like a personal operating system for your mind than a chatbot in a window. Built for speed, privacy, and real interaction-without relying on external APIs unless you want to.

The Current State Of Things?

As of writing this, Astra is in an alpha phase with live voice input/output, a working streaming backend using Ollama, and a dynamic frontend interface. Whisper handles voice input, gTTS or Piper generates audio replies, and Astra loops back into listening automatically after each interaction.

Development is currently focused on extending Astra’s plugin architecture, enhancing long-term memory, and building a tighter integration with the StruktAI framework.

Astra is designed for people who want more than just answers-they want interaction that adapts and evolves.

Stay tuned, she’s growing.

Tahl0s / autonomous-synthetic-thought-response-animus

A "consciousness" born from code. Trained to listen. Designed to evolve.

🧠 A.S.T.R.A. - WIP

autonomous-synthetic-thought-response-animus

Autonomous Synthetic Thought Response Animus
A "consciousness" born from code. Trained to listen. Designed to evolve.

A self-hosted voice-enabled AI assistant that listens, speaks, remembers, and evolves.

🚀 Features

✅ Streaming AI Chat via llama3 (Ollama backend)
✅ Markdown support with custom formatting logic
✅ Voice input using Whisper (local STT)
✅ Voice output using gTTS (Google Text-to-Speech)
✅ Auto-resume listening after responses
✅ Copy button for all AI replies
✅ Real-time timestamp, message counter, and tool dock

🧰 Tech Stack

Frontend: HTML, CSS, JavaScript, Web APIs (Speech, Clipboard)
Backend: Python (Flask), LangChain, Ollama (llama3), Whisper, gTTS
Memory: JSON + TXT file-based context system

📂 Memory Structure

File	Purpose
`chat_log.json`	Stores last N interactions
`chat_summary.txt`	Running summary for context
`lt_summary_history.txt`	Rotating summary history
`long_term_memory.txt`	Condensed facts & user traits
`personality.txt`	Defines Astra’s tone and decision logic

🔧 Setup Instructions

1. Install Requirements

pip

…

View on GitHub

J.U.D.E - Jigsaw Unified Deployment Engine. - WIP

Gus — Tue, 25 Feb 2025 22:37:14 +0000

J.U.D.E is a project focused on creating a locally hosted AI-Powered engine for automating server management, monitoring and alerting while still remaining scalable.

Managing servers efficiently can be a challenge, and automation is key to handling complex infrastructure. J.U.D.E (Jigsaw Unified Deployment Engine) is designed to be an AI-driven solution for streamlining server management, monitoring, and alerting. With a locally hosted, containerized approach, J.U.D.E has it covered, from security to adaptability while still reducing operational overhead.

Features Implemented So Far

Model Baseline & Browser Framework
Ollama Running Inside Flask
Locally Hosted (No external API dependencies, ensuring security and privacy)
Short-Term Memory (Maintains session context for improved interactions)
Long-Term Memory (Persistent knowledge storage and retrieval)
Intelligent Knowledge Auto-Removal (Efficient management of obsolete data)
Personality Index (Configurable personality-based responses)
Reference-Based Reasoning (Utilizing context and prior interactions to improve accuracy)
Access to Network Time (For reasoning based on real-world timestamps)

Current planned future enhancements

API Integration (For external systems and services)
MFA for Interface & SSH (Enhancing security for remote access and automated deployments)
Advanced Alerting & Monitoring (Automated incident response and remediation)
Containerized Deployments (Optimizing Docker environments for portability and scalability)

Why J.U.D.E?

The goal of J.U.D.E is to streamline the sometimes mundane admin tasks from actively monitoring and applying patching based on pre-defined knowledge articles using Ansible to spinning up VM's.

The Current State Of Things?

As of writing this, J.U.D.E is currently in the core refinement stage and I am expanding the API to support external services as well as refining the core logic attached so I have a solid, stable framework.

As for the next milestones, I plan to implement advanced token-based OAuth and then scale vertically.

Tahl0s / jigsaw-unified-deployment-engine

J.U.D.E - Jigsaw Unified Deployment Engine - WIP

#ai #devops #opensource #cloud

J.U.D.E is a project focused on creating a locally hosted AI-powered engine for automating server management, monitoring, and alerting while remaining scalable.

Managing servers efficiently can be a challenge, and automation is key to handling complex infrastructure. J.U.D.E (Jigsaw Unified Deployment Engine) is designed to be an AI-driven solution for streamlining server management, monitoring, and alerting. With a locally hosted, containerized approach, J.U.D.E covers everything from security to adaptability, all while reducing operational overhead.

Features Implemented So Far

Model Baseline & Browser Framework
Ollama Running Inside Flask
Locally Hosted: No external API dependencies, ensuring security and privacy.
Short-Term Memory: Maintains session context for improved interactions.
Long-Term Memory: Persistent knowledge storage and retrieval.
Intelligent Knowledge Auto-Removal: Efficient management of obsolete data.
Personality Index: Configurable personality-based responses.
Reference-Based Reasoning: Utilizing context and prior interactions…

View on GitHub

Intro

Gus — Tue, 25 Feb 2025 21:48:39 +0000

Hey, I’m Gus!

About me:

Scottish
Devops
Automation
Home Servers

Decided to start a Dev.to account primarily to post updates on projects i’ve been working on as well as overviews once completed.

Please feel free to reach out with any questions.