Deploy Sight

The Problem

Modern teams ship across several platforms at once — Netlify here, GitHub Actions there, AWS somewhere else. Every one of them reports its own deployments perfectly well, and none of them report anyone else's.

So the simplest questions get answered by opening four dashboards: what shipped, where did it ship, did it succeed, and when.

Approach

Deploy Sight ingests deployment webhooks from each provider, normalizes them into one shared model, and persists them. The dashboard reads back a single source of truth: summary cards for total, successful, failed, and in-flight deployments, above a table of every deployment with its repo, branch, environment, status, commit, and timestamp.

The surface area is deliberately narrow — the questions a small team actually asks, answered in one place.

Architecture

Every hosting provider emits a different webhook payload. Deploy Sight keeps that difference at the edge: a ports-and-adapters layer defines a single WebhookParser contract, each provider gets an adapter that satisfies it, and a registry resolves the right one per request.

Everything past that boundary speaks one normalized deployment model, so the domain logic stays provider-agnostic and adding a platform means adding an adapter — not touching the core.

Technical Implementation

• TypeScript across the full stack
• Node.js + Express API with a repository and service layer
• PostgreSQL via TypeORM, containerized with Docker Compose
• Webhook ingestion from Netlify and GitHub Actions
• React 19 + Vite frontend
• Material UI with MUI X DataGrid for the deployment table
• TanStack Query + Axios for server state
• ngrok for local webhook testing

Why It Matters

Visibility shouldn't be a privilege of scale. Deploy Sight treats restraint as a design decision — the value is in what it leaves out as much as what it shows.