Vercel + GitHub Actions + Kubernetes: One Deployment Dashboard

Modern applications rarely deploy from a single place. Your marketing site ships through Vercel. Your backend deploys to Kubernetes via GitHub Actions. Your mobile API might go through Semaphore CI. Each provider has its own deployment dashboard, its own notification system, and its own way of presenting deployment history. The result is that nobody on your team has a clear answer to the simplest question in infrastructure: "What deployed where, and when?" CPI-Control answers this question by aggregating deployments from every provider into a single, unified timeline.

The Problem: Deployment Blindness

When a production issue appears, the first question is almost always "Did something deploy recently?" If your team deploys through three different platforms, answering this question means checking three different dashboards. You open Vercel to see if a frontend deploy went out. You check GitHub Actions to see if a backend workflow ran. You run kubectl rollout historyto see if a Kubernetes deployment was updated. By the time you've checked everything, five minutes have passed, and you still might have missed a deploy from a service you forgot to check.

This fragmentation also makes it impossible to correlate deployments across services. If the frontend and backend deployed within minutes of each other, and the issue started between those two deploys, that's critical debugging information. But if you're looking at each provider in isolation, you won't notice the timing correlation.

Setup: Connect Your Providers

Setting up unified deployment tracking in CPI-Control takes about five minutes. Navigate to Settings → Integrationsand add each provider. For Vercel, create a personal access token in your Vercel account settings (Account → Tokens) and paste it into CPI-Control. For GitHub, generate a fine-grained personal access token with read access to your repositories and actions. For Kubernetes, upload your kubeconfig as described in our Kubernetes setup guide. For Semaphore, add your API token and organization name.

Each provider connection is verified immediately after you add it. CPI-Control will show a green checkmark if the token is valid and has the required permissions, or a clear error message if something is wrong. Once connected, CPI-Control starts syncing deployment data automatically. Initial sync pulls recent deployment history, so you'll see past deployments immediately, not just new ones going forward.

Auto-Discovery: Services from Every Provider

After connecting your providers, CPI-Control auto-discovers your services. Vercel projects become services. GitHub repositories with workflow files become services. Kubernetes Deployments become services. Semaphore projects become services. Each service is tagged with its provider, so you can see at a glance which platform manages it. The discovery process runs continuously, so when you create a new Vercel project or add a new GitHub Actions workflow, it appears in CPI-Control automatically.

CPI-Control is also smart about avoiding duplicates. If a GitHub repository deploys to a Kubernetes cluster, CPI-Control recognizes this as the same service managed by two providers rather than creating two separate entries. The service shows both the GitHub repository information (commits, branches, CI status) and the Kubernetes runtime information (pods, health, metrics) in a single view. This deduplication is based on naming conventions and infrastructure bindings, and you can manually link services if the automatic matching doesn't catch a connection.

The Deployment Timeline

The deployment timeline is the core feature for cross-provider visibility. It presents every deployment from every connected provider in a single, chronologically sorted table. Each row shows the service name, the provider logo (Vercel's triangle, GitHub's octocat, Kubernetes' wheel, Semaphore's flag), the last commit message, the deployment status (success, failed, in progress, cancelled), the duration from start to finish, and a direct link to the deployment on the original provider's dashboard.

The timeline is sortable by any column. Sort by time to see the most recent deploys first. Sort by status to group all failures together. Sort by service to see the deployment history of a specific application. The table supports infinite scrolling, loading older deployments as you scroll down, so you can trace deployment history back weeks or months.

Provider Filter Pills

Above the deployment timeline, a row of filter pills lets you quickly narrow down the view by provider. Click the Vercel pill to see only Vercel deployments. Click GitHub Actions to see only CI-triggered deploys. Click Kubernetes to see only cluster rollouts. The pills are toggleable — you can activate multiple at once to see, for example, only Vercel and GitHub deployments while hiding Kubernetes rollouts. Each pill shows a count of deployments from that provider in the current time range, giving you a quick sense of deployment volume per platform.

Beyond provider filtering, the timeline supports text search across commit messages, service names, and branch names. If you know a specific feature branch name or a commit keyword, you can find its deployment instantly without scrolling through hundreds of entries.

What Each Deployment Shows

Click on any deployment row to expand its details. The expanded view varies by provider because each platform provides different metadata, but the core information is consistent. Every deployment shows the triggering commit SHA and message, the branch it was deployed from, the start and end time with duration, and the final status. For GitHub Actions deployments, you'll also see the workflow name, the specific job that ran, and any artifacts produced. For Vercel deployments, you see the deployment URL (both the unique deployment URL and the production alias), the framework detected, and build output size. For Kubernetes rollouts, you see the image tag that was deployed, the rollout strategy (rolling update or recreate), and the number of pods updated.

Each expanded deployment also includes a direct link to the original provider's deployment page. If you need to see full build logs or trigger a redeployment, you can jump straight to the source with one click. CPI-Control is a monitoring and aggregation layer — it doesn't try to replace your providers' dashboards, it ties them together.

Push Notifications for Deployment Failures

One of the most valuable aspects of unified deployment tracking is unified alerting. Instead of configuring notification webhooks in Vercel, GitHub, Semaphore, and your Kubernetes cluster separately, you configure notifications once in CPI-Control. Enable deployment failure notifications and you'll get alerted whenever a deploy fails, regardless of which provider it came from.

Notifications are delivered through the operating system's native notification system (macOS Notification Center or Windows Notifications) and as in-app toast messages. Each notification includes the service name, the provider, the commit message, and the failure reason when available. Clicking a notification takes you directly to the failed deployment's detail view in CPI-Control, where you can see what went wrong and jump to the provider's build logs if needed.

You can also configure success notifications for critical services. If your production API deploys successfully, you might want to know about it immediately so you can monitor the rollout. For less critical services, you can limit notifications to failures only, keeping your notification volume manageable.

Deployment Correlation

The real power of a unified deployment dashboard emerges when you start correlating deployments across providers. CPI-Control automatically identifies deployments triggered by the same commit across different services. If a single git push triggers a Vercel deployment of your frontend and a GitHub Actions workflow that deploys your backend to Kubernetes, CPI-Control groups these as related deployments. You can see them linked in the timeline, making it obvious that they're part of the same change.

This correlation extends to branch-based workflows. If you deploy a feature branch to a preview environment on Vercel and simultaneously deploy the same branch to a staging namespace on Kubernetes, CPI-Control shows these deployments as related. When you later merge the branch and the production deployments trigger, those are linked too. The result is a complete audit trail from feature branch to production, across all providers, without any manual tagging or metadata management.

For incident response, deployment correlation is invaluable. When you identify a problematic deployment in production, you can instantly see every other deployment that went out around the same time, across all providers. This cross-provider context often reveals the root cause faster than investigating each service in isolation.