Deploy an Existing GitHub Repository From Your Coding Agent

From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

An existing GitHub repository already contains the part a host cannot invent: a reviewable history of code. Your agent should connect that repository to a named Project, build one stated branch, and report the commit and address that result. Do not treat a chat instruction as a substitute for a push. The repository remains the record; the build turns one recorded revision into a running service.

Connect the agent before asking it to deploy

Install the platform connector in the agent you already use, approve its sign-in screen, and keep the repository in GitHub under your team's own access. The agent can then see the Projects and repositories it is allowed to operate. It does not need a copied personal token in a prompt.

For Codex CLI, the current installation path is:

codex plugin marketplace add aidropit/plugins --sparse .agents/plugins
codex plugin add aidropit@aidropit
codex mcp login aidropit

The connector gives the agent a way to call the hosting tools. It does not give the host permission to edit your GitHub history. Code should enter a host through Git because the commit, author, and diff are the evidence you need when a release goes wrong.

Turn a repository into one named Service

Ask the agent for a small, explicit result. It should create or select the Project, list accessible repositories, then build one Service from an owner/repository reference. Give it the application facts Git cannot decide: runtime kind, port, health path, size, and the names of values the process reads.

Create a Project named "Support Desk" for our customer support application.
List the GitHub repositories available to it and use acme/support-desk.

Build a Service named "api" from main. It is a python_http application on
port 8000 with health path /health. It reads DATABASE_URL and SMTP_PASSWORD.
If either value is missing, stop and tell me its name. Do not invent a value.

Poll the Service. When it finishes, report the branch head, built commit,
image tag, and public address. When it stops, report the stage and build log.

This prompt makes the boundary visible. A Service has a name and an owner; the repository has a tracked branch; values reach the process only by name. You can later add a worker or a static frontend without making an unrelated folder share an application lifecycle.

Treat the build result as a decision point

A build takes minutes and may stop for a reason the repository did not show: the app listened on the wrong port, the health path answered an error, or a required value was never stored. Read the stated failure before changing code. One change justified by a log is diagnosis; repeated attempts against the same failure are guessing.

After a successful build, save the built commit and public address in the release record. The next agent session should read the live state first. The branch that builds is a setting and can differ from the branch a developer happens to have checked out.

For a project built in Claude Code, the public-link check verifies that another device can open the app and complete the action you intend to share.

A repository-to-address checklist

Copy this into the issue or pull request that authorises a first release. It separates the choices a developer makes from the facts the agent can report.

REPOSITORY TO ADDRESS
[ ] Project name and responsible person are known
[ ] GitHub App can see owner/repository
[ ] Tracked branch is named
[ ] Runtime kind, port, and health path are stated
[ ] Required values are listed by name, never copied into the issue
[ ] Everyone responsible knows the first address is public
[ ] Build result records commit, tag, address, or the stopped stage and log
[ ] A later session reads the live Service before changing code

FAQ

Can an agent deploy a GitHub repository without copying my GitHub token into a chat? Yes. Connect the agent through the hosting connector and grant repository access through the GitHub App or your existing GitHub integration. The agent works from the repository reference it is allowed to see; keep your Git credential under your own control.

Why do I need to state a port and health path? A repository describes source code, while a running application must listen on a specific container port and answer a checkable HTTP path. Naming both prevents the host and the agent from guessing what counts as a healthy process.

What happens if the application needs a missing secret? Stop and supply it through the approved value-setting path. An agent may identify the missing name, but it must not make up a credential, paste one into the repository, or weaken the application so the check disappears.

How does this work on the platform? After you connect the aidrop.it MCP plugin, service_build accepts a GitHub owner/repository that the Aidrop GitHub App can reach. It builds the named branch, creates the Service on the first call, then service_get reports the build stage, commit, address, and a redacted log if the build stops.