Bring a Service · aidrop.it Docs

Code that already exists takes a different route from code aidrop.it starts for you: the repository is on GitHub rather than created here, and it is the authority on how it builds. Both routes end in the same place — one service_build, naming the repository and the port the application listens on.

If you have no code yet, the quickstart is the shorter road.

The whole page, said once:

I have a GitHub repository, acme/support-portal. Bring it
into aidrop.it as a
Service, build it here, and tell me what is missing if it
does not run.

1. Look at the Team’s repositories first

repositories_list is the Team’s repositories — the ones on its own aidrop.it Git service and the GitHub ones the aidrop.it GitHub App can reach — with the Services each one already backs. A repository can already back a Service, and this tells you which, so you continue in the Service that exists instead of starting a parallel one by accident.

It is not a refusal. One repository may back several Services, and sometimes it must: a Service runs one container on one port, so a monorepo whose API and web app are separately deployable is two Services over one repository.

Your agent does this before creating anything — it is part of the Service rules aidrop.it gives it. If the repository already backs a Service in your Team, it offers you that one and asks whether you want it, rather than quietly creating a second.

2. Name the deployable

There is no create call: service_build makes the Service on its first call, from the Project and a name you give it. Tell your agent to read the repository first and describe what it found, so what gets recorded matches the code rather than a guess made before anyone looked.

Read the repository and tell me what it is before you
create anything.

It shows you what it read from your code and waits for a yes.

Nothing is copied into your repository at any point: your code stays yours.

3. Build it — the first build links the repository

Build it on aidrop.it.

service_build(
  service_id: "8b3e…",
  repository_ref: "acme/support-portal",
  container_port: 8000
)

There is no separate connect step: the first service_build names the repository and it becomes the Service’s, for good. Your repository is the authority on how it builds, and aidrop.it does not read it to guess: service_build takes the port the application listens on, a health path if it is not /, and how the image is built — inferred by nixpacks unless build_type: dockerfile names yours. The build is queued, the address is reserved by the deploy itself, and your agent polls service_get until it answers a running application.

Code that is not on GitHub goes through repository_create instead: it makes an empty repository on your Team’s own Git service and answers a credential your agent pushes with using its own git, and the same service_build links it.

A Dockerfile is optional. The default build_type is nixpacks: it infers the build from your repository and writes the Dockerfile itself, so code with none still builds and deploys. What you give up is certainty — an inference is a guess nothing has checked, and for some shapes it produces an image that builds and then exits.

To build your own instead, pass build_type: dockerfile and build_dockerfile_path — the file’s path in the repository, with its name: Dockerfile, or build/Dockerfile.api in a monorepo. It can live anywhere; the repository root stays the build context, so its COPY paths are the ones you would write from the root. Aidrop never reads your code to switch, so a Dockerfile nobody named is never opened. The runtime_envelope in service_get carries one written for this platform.

4. If it does not run

service_logs says why. Your agent reads it, changes the code, pushes to the tracked branch — pass branch to service_build if the code to run is on another one — and builds again. The address is in what you get.

Next steps

Service lifecycle — the same cycle end to end, including what only a person can do.
Runtime templates — the shapes a Service can take, and what each one needs to run.
MCP server — the whole surface an agent gets, tool by tool.