Connect aidrop to your coding agent
Use the computer where your coding agent and repository live. A local coding agent can edit files and push with git; a chat-only MCP client cannot upload your local app.
Create an aidrop account
Create a free account or use the account you already have. The 7-day trial includes one app and a PostgreSQL database. No credit card is required; your coding agent subscription is separate.
Add aidrop to your agent
Claude Code and Codex use the aidrop plugin. Cursor uses an MCP connection. Choose your agent below for its installation commands or install link, account step and first deployment task.
Sign in and approve Team access
When the agent opens the browser sign-in flow, use your aidrop account, choose the Team and review the requested read or write access. OAuth handles authentication; there is no aidrop API key to create or paste into your application. Ask the agent to list your Projects to check the connection.
Another OAuth-capable MCP client can connect to https://aidrop.it/mcp. Read the full quickstart
Five steps from code to URL
You work through the coding agent you use now. aidrop handles the repository connection, build record, runtime and address behind that conversation.
- Connect your coding agent
Claude Code, Codex, Cursor and other MCP clients connect through a browser consent screen. OAuth keeps API keys out of the chat.
- Choose where the code lives
Use aidrop Git or connect a GitHub repository. Your coding agent writes the code and pushes it with git.
- Ask the agent to deploy
The agent names the repository, the port and the build method. aidrop builds the selected revision and starts the app.
- Read the build result
The build record shows the stage it reached. If it stops, the agent can read the log, change the code and build again.
- Open the public URL
The first successful deployment gets an aidrop address. Later deployments update the same service and keep its history.
Your tools stay in place
Two source choices
| Source | The setup | The code |
|---|---|---|
| aidrop Git | Your agent creates an empty repository and receives a git credential for your Team. | The agent writes on your machine and pushes with git. You can clone the repository at any time. |
| GitHub | Install the aidrop GitHub App, then choose a repository it can read. | The repository stays on GitHub. aidrop follows the branch the service tracks. |
aidrop does not write source code or commit on your behalf. A coding agent with a local shell can edit and push. A chat-only client can work with code that has reached a repository, but it cannot push local files for you.
One connection, one Team
Your agent connects over MCP through OAuth. The consent screen shows read or write access for one Team. A Team admin can see the connected app and revoke it in the dashboard.
Team membership controls the project records, repositories, build history and runtime values. It does not make a deployed app private.
The deployed app is public
The first successful deployment opens an aidrop address to the internet. Anyone with the address can visit it. Add sign-in to your application before deployment if visitors must authenticate.
One request starts the build
Your agent sends the repository, the app's port and its build settings. The first request creates the deployable service inside your project. Later requests build the same service again.
Nixpacks or your Dockerfile
Nixpacks is the default and infers a build from the repository. A Dockerfile is optional. To use one, your agent selects the Dockerfile build method and names its path. aidrop will not switch to a Dockerfile because one happens to exist in the repository.
The runtime settings stay with the service
| Setting | Purpose | Default |
|---|---|---|
| Port | The port the app listens on inside its container. | Required on the first build |
| Health path | The HTTP path used to confirm that the app can serve requests. | / |
| Size | The CPU and memory reserved for the app. | The smallest size in the plan |
| Build method | Nixpacks inference or a named Dockerfile. | Nixpacks |
| Runtime values | The names of Project secrets passed to this service. | None |
Read the build result and logs
A build record follows the revision through build, runtime checks and deployment. The agent polls that record until it succeeds or stops. On failure, it reads the bounded build log, changes the code and starts another build.
Ask the agent for the build status, the stage it reached and the log if it failed. A failed attempt and the deployment currently serving traffic are separate records: ask which revision is running before treating the latest build as the live application.
The next session reads the same deployment
The service keeps its repository link, runtime settings, address and build history. The next coding session can read the current state before it changes anything.
What runs where
| Part | Where it runs | What it does |
|---|---|---|
| Your coding agent | Your computer or existing development environment | Edits the repository, pushes code and calls aidrop over MCP. |
| aidrop control plane | The shared aidrop platform | Checks Team access and keeps Projects, service settings and build records. |
| Your app and backing resources | An aidrop managed runtime cluster | Runs the deployed code and the database, cache or queue attached inside its Project. |
Shared runtime or a cluster of your own
Starter, Pro, Scale use a runtime shared with other Teams. Project networks separate an application and its backing resources from other Projects. Each app still has its own CPU and memory reservation.
Business includes a runtime cluster reserved for your Team's workloads. The agent connection, dashboard and deployment records still use the same aidrop control plane. A dedicated runtime does not make an application's public address private.
Application files use temporary scratch space. External connections must use HTTP or HTTPS. Read the storage limits and network limits before choosing how your app keeps data.
Size your app and its backing resources
Projects hold products, services run code
A Project is the product you are building. A Service is one deployable part inside it, such as a web app, API or worker. Each Service has its own build, address and runtime settings. Project secrets and backing resources stay inside their Project.
Plans count Projects. Applications and backing resources share the Team's CPU and memory allowance. Adding a database uses capacity, but it does not use another Project slot.
How the capacity adds up
Add the CPU and memory reserved by every application and backing resource in the Team. Both totals must fit the plan, and the Project count is a separate limit. A larger application or database leaves less capacity for the other parts.
| One example Project | CPU reserved | Memory reserved |
|---|---|---|
| compact application | 1 vCPU | 1 GB |
| Default PostgreSQL | 0.25 vCPU | 256 MB |
| Total | 1.25 vCPU | 1.25 GB |
Pro includes 2 Projects, 3 vCPU and 3 GB. Two Projects with the setup above reserve 2.5 vCPU and 2.5 GB in total, so they fit. Capacity is counted from reservations, rather than measured CPU activity. A request that exceeds the allowance is refused; it does not evict an app already running.
Application sizes
| Size | CPU | Memory | Available from |
|---|---|---|---|
| micro | 0.5 vCPU | 512 MB | Starter and above |
| compact | 1 vCPU | 1 GB | Pro and above |
| dual | 2 vCPU | 2 GB | Pro and above |
| medium | 2 vCPU | 4 GB | Scale and above |
| large | 4 vCPU | 8 GB | Business |
Backing resources
| Resource | Use it for | Available from |
|---|---|---|
| PostgreSQL | Records that must survive a restart. The default instance reserves 0.25 vCPU and 256 MB. | Pro, $20/month |
| Valkey cache | Sessions, counters and data your app can recreate. | Scale, $99/month |
| Valkey queue | Jobs that should run after the request ends. | Scale, $99/month |
Files inside the app do not persist
The container's root filesystem is read-only. Scratch paths are available while the app runs, but their files do not survive a restart. Store durable records in a database and send uploads to object storage over HTTPS.
Daily snapshots and your own exports
aidrop takes daily snapshots. You can also keep an independent export. Your agent can read a small database in pages over MCP. For a larger database, it can run pg_dump from a service inside the Project and send the file to storage you own.
Which plan a build needs
Choose the resources and domain your app needs, then check its application size and the Team's remaining allowance. The examples below describe typical setups; the repository's actual needs decide whether it fits.
| Plan | A typical build | When you need more |
|---|---|---|
| Starter · $5/month | A landing page, static site or small HTTP app within Micro, with no managed database and an aidrop address. | A managed database, your own domain or an application larger than Micro requires another plan. |
| Pro · $20/month | A small app or store with PostgreSQL and a custom domain, within the Team's capacity. | A cache, queue or Medium application requires Scale or above. |
| Scale · $99/month | A SaaS app, CRM or marketplace using PostgreSQL, cache and a queue for background work. | A Large application or a dedicated runtime requires Business. |
| Business · $299/month | Several products or internal tools on a runtime cluster reserved for your Team. | Check the included Project count and total CPU and memory against your full workload. |
The trial includes one Micro app and default PostgreSQL for 7 days. Free includes no hosting after the trial. Compare every plan limit
Managed data or an external HTTPS API
A project can use PostgreSQL that aidrop runs beside the app. It can also call services you already use when they expose an HTTP or HTTPS API.
| Connection | Supported | Reason |
|---|---|---|
| Managed PostgreSQL inside the Project | Yes | The connection stays on the Project's private network. |
| An external service over HTTPS | Yes | Outbound HTTP on port 80 and HTTPS on port 443 pass through the egress proxy. |
| An external database over port 5432 | No | Raw outbound sockets outside ports 80 and 443 are blocked. |
Store connection strings and API keys as Project secrets. A service receives the values it declares by name. No tool or dashboard screen returns a stored value after it has been saved.
Use the aidrop address or connect your domain
Get and open the public URL
Every deployed service receives an aidrop address. Custom domains start on Pro, at $20/month.
After a successful deployment, ask your agent for the Service's public URL and the revision currently running there. Open the returned HTTPS address in your browser and check the app's main flow. Later deployments of the same Service keep its address. Anyone with the URL can visit; add sign-in inside your app when visitors must authenticate.
Connect a domain you own
Your agent claims the hostname and returns the DNS record to create. After the record reaches aidrop, the agent verifies the hostname and publishes it for the service. Certificate issuance can take a few minutes after verification.
Root domains need an apex record
A subdomain such as app.example.com uses a CNAME. A root domain cannot use a standard CNAME, so aidrop returns an A record or an apex alias instruction. Use ALIAS, ANAME or CNAME flattening when your DNS provider offers it.
Cloudflare proxying works
Domain verification sends a request through the hostname instead of reading its DNS answer. The Cloudflare proxy can stay on. Set the Cloudflare origin connection to Full or Full (strict), not Flexible, so traffic stays encrypted between Cloudflare and your app.
Deploy one app before you choose a plan
The 7-day trial includes one app and one managed PostgreSQL database. No credit card is required. Ask your agent to deploy a repository and inspect the result before you pay for hosting.
Start the 7-day trialNeed the plan limits first? Compare plans.