GITHUB DEPLOYMENTS
Connect your repository, configure your Dockerfile, and follow your code from a specific source revision to a container image and its deployment outcome. Automatic deployment is an explicit opt-in for matching branch pushes.
Authorize the GitHub App, grant repository access, and connect the installation to an iDeployed project.
Select a repository and branch, then set the Dockerfile path and build context.
Request a build from an exact commit and follow the resulting artifact into a deployment.
THE JOURNEY
Install the GitHub App and select exactly the repositories it may access. You choose the scope; nothing else is implied.
Point iDeployed at the source that should become your application. A Dockerfile-based example works across many languages — no framework-specific magic.
Every build is tied to an exact commit. Follow build output live, and see the resulting container artifact published and recorded.
12:02:11 BUILD a3f82c1 — “Add warehouse fleet overview”
12:03:04 PUSHED atlas:v1.2
12:03:04 CHECK build passed on a3f82c1 ✓
A source connection, a successful build, and a running deployment are distinct steps. Follow each one, then inspect the running application and its logs.
A CONNECTED WORKFLOW
Source revision, build identity, image digest, and deployment identity are different pieces of the same release. iDeployed keeps those pieces traceable, and GitHub check feedback connects source changes to build and deployment outcomes — right on the commit.
Connecting a GitHub account alone does not start a build. You choose the repository, branch, and build configuration before requesting the next step.
TWO RESULTS, CLEARLY SEPARATED
A build produces and publishes a container image. A deployment runs that artifact with your application’s configuration. The image can build successfully even when an application later fails to start — so build output, deployment history, and runtime logs each tell their own part of the story.
YOUR NEXT CHAPTER
Bring your code. Make something people can use.
