dev@portfolio:~
back to projects
>_

AutoDeploy — From Source Code to a Running Application

A self-hosted deployment platform that turns source code into a running application.

Connect

Link a Git repository and provide the deployment configuration.

Automate

Build, validate and deploy the application automatically.

Observe

Track deployment progress and application status from one interface.

• Personal Project • GitHub repository ↗

Project Status
Active development
Type
Personal project
Category
Platform as a Service

project_overview

What I built

I built a self-hosted platform that automates the process of turning source code into a running application.

technology_stack

Application
Vue.js Python Flask SQLAlchemy MySQL
Platform & Deployment
Docker Docker BuildxKubernetesHelm
Engineering & Quality
PytestAlembicGitDocker Compose

>_This stack supports application development, repeatable deployment and continuous quality checks.

Why I built it

Deploying an application involves many repetitive steps across different tools. Doing them manually takes time and increases the risk of errors.

I built AutoDeploy to learn how modern platforms automate this process and keep their records aligned with the applications that are actually running.

Result

A working end-to-end deployment platform that can take an application from source code to a running service, while tracking its progress and recovering from common failures.

It supports both local Docker deployments and Kubernetes environments.

My role

I designed and implemented the platform end to end, from the web interface and backend services to the deployment workflow, Kubernetes integration, testing, and local development environment.

I also made the main architectural and reliability decisions behind the system.

architecture

AutoDeploy separates user interactions, deployment execution, and system recovery. Each component has a clear responsibility, making the platform easier to maintain and more reliable when something fails.

  1. 01

    Configure a deployment

    The operator selects a project, provides the required settings, and starts a deployment from the web interface.

    Operator → Vue Console → Flask API

  2. 02

    Store the request

    The API validates the request and records what the platform needs to do.

    Flask API → MySQL

  3. 03

    Build and launch

    A background worker retrieves the source code, builds and tests it, then launches the application.

    Worker → Build & Test → Docker / Kubernetes

  4. 04

    Keep everything in sync

    The platform continuously checks that what is running matches what was requested and repairs inconsistencies when possible.

    Database ↔ Reconciler ↔ Runtime

AutoDeploy Control Plane — Architecture Overview

Architecture outcomes

  • Clear responsibilitiesEach component has a focused role, making the system easier to maintain and extend.
  • Background processingDeployments run independently from the web interface, so long-running work does not block the user.
  • Recovery by designThe platform detects interrupted work and differences between expected and actual runtime state.

deployment_flow

Each deployment follows a controlled process that turns source code into a running application. AutoDeploy performs the work in the background, records the progress of every step, and stops the process if a critical check fails.

  1. 01

    Configure

    Provide the source repository, branch, build settings, and deployment preferences.

  2. 02

    Retrieve

    Download the source code and lock the deployment to the exact requested version.

  3. 03

    Build & Test

    Package the application into a container image and run its automated tests.

  4. 04

    Publish & Deploy

    Prepare the verified image and launch the application using Docker or Kubernetes.

  5. 05

    Verify

    Confirm that the application started successfully and passes its health checks.

Technical deployment details
  • Each deployment is tied to an exact Git commit, making builds reproducible and traceable.
  • Builds and automated tests must succeed before an application can be deployed.
  • Kubernetes deployments publish and verify the container image before updating the workload.
  • Deployment progress and state changes are persisted throughout the process.
  • Final health checks confirm that the application is actually running successfully.

NoteLocal Docker can run the image directly, while Kubernetes deployments publish it to a registry before updating the workload.

key_engineering_decisions

The main design choices that make deployments reliable, traceable, and adaptable across different environments.

01

Separate system responsibilities

The API records requests, the worker executes deployments, and the reconciler detects inconsistencies.

Why it matters →

Long-running work stays isolated, so one failure does not block the entire platform.

02

Store deployment state centrally

Projects, builds, deployments, commands, and status history are stored in a shared database.

Why it matters →

Components stay consistent, and interrupted work can be detected and recovered after a restart.

03

Use one workflow for multiple runtimes

A shared execution layer allows the deployment pipeline to work with local Docker and Kubernetes.

Why it matters →

New runtime options can be added without redesigning the complete deployment process.

04

Verify before and after deployment

Applications are tested before launch and health-checked after they start.

Why it matters →

Failed builds stop early, while successful deployments are confirmed to be actually reachable.

challenges_and_trade_offs

AutoDeploy intentionally favors a manageable, end-to-end deployment platform over production-scale complexity. These trade-offs keep the project focused while leaving clear paths for future hardening.

01

Database-backed work queue

Why
Reuse the existing database instead of adding another infrastructure component.
Trade-off
Simple and recoverable, but less efficient at high job volumes.
Production path
Introduce a message broker for faster delivery and independent worker scaling.
02

Trusted build environment

Why
Keep builds practical for a local/demo environment.
Trade-off
Build instructions are trusted and not isolated enough for untrusted workloads.
Production path
Run builds in temporary sandboxed environments with strict resource and network limits.
03

Basic platform observability

Why
Prioritize the complete deployment lifecycle before adding a full monitoring stack.
Trade-off
Deployment status and failures are visible, but metrics, tracing, and alerts remain limited.
Production path
Add centralized logs, metrics, tracing, dashboards, and automated alerts.
04

Single control-plane environment

Why
Focus on deployment orchestration without introducing multi-tenant or multi-region complexity.
Trade-off
Works well as a single trusted control plane, but is not designed for large isolated workloads.
Production path
Add tenant isolation, RBAC, quotas, high availability, and multi-cluster support.
Additional technical constraint

AutoDeploy is designed as a trusted, operator-facing control plane rather than a public hosting platform. The current implementation assumes trusted access to its Docker or Kubernetes runtime and does not implement hardened multi-tenancy, automated TLS management, autoscaling, or multi-cluster scheduling.

lessons_learned

Every step needs to be tracked

A deployment spans multiple stages, so the platform must always know what is running, completed, or still pending.

Failures are expected, not exceptional

External tools and background processes can fail at any time, so recovery must be part of the normal workflow.

Records and reality can differ

Stored state can drift from what is actually running, so the platform must continuously compare and reconcile both.

Running does not always mean working

Starting an application is not enough; health checks must confirm that it is actually reachable and usable.

future_improvements

  1. 01

    Isolate untrusted builds

    Run builds in temporary, restricted environments with resource limits, controlled network access, and no direct host access.

  2. 02

    Add release rollbacks

    Keep previous successful releases and provide a safe way to restore an earlier version after a failed deployment.

  3. 03

    Strengthen observability

    Centralize logs, collect metrics, and add dashboards and alerts for deployment failures.

  4. 04

    Scale job processing

    Introduce a message broker and independently scalable workers to handle more deployments efficiently.

architecture_diagrams

Detailed views of the AutoDeploy architecture, deployment lifecycle, runtime sequence, data model, reconciliation flow, and security boundaries.