Runtime settings, sizes and plans

Every app on aidrop.it runs in a small box with fixed rules: one port, a health check, a memory size and no permanent disk. This page lists those settings, the sizes, what each plan includes and the databases, caches and queues you can add.

Nothing is detected. Your agent passes every setting to service_build, or the default applies. aidrop.it never reads your repository to decide the port, the size or the health path. The one thing it can work out is how to build the image when you have no Dockerfile. A build is the only thing that says a version does not run here. The Service lifecycle shows where these settings fit between the first build and a rollback.

The settings answer four questions:

Beside them, required_secret_names lists the names of the secret values the app reads. The values themselves live on the Project, and no read ever answers one.

The runtime kinds

A runtime kind is a family of apps that aidrop.it has a starter Dockerfile for. service_get answers a runtime_envelope, the limits and rules your code must fit. It carries a dockerfile for this Service’s kind: the plainest one for that family, binding the PORT the platform sets, built and run under the platform’s rules.

To use it, commit it, name it in service_build with build_type: dockerfile and build_dockerfile_path, and adjust the lines marked CHANGE ME. The default kind, container, has no starter Dockerfile: it is the kind for an image that already knows how to run itself.

These are conventions, not detections: service_build records the port you pass, whichever kind you name. There is one starter Dockerfile per kind. It is precise about the platform’s rules and leaves your project layout to you.

Prefer a Dockerfile of your own to letting the build be inferred. With build_type unset, the image is built by nixpacks, an open-source builder that picks a language version from what the repository declares. When the repository declares nothing, it picks an old default:

• an undeclared Node application is built with Node 18;
• requires-python in pyproject.toml is ignored;
• Go 1.22 and 1.24 resolve to an unspecified toolchain without raising an error.

Declaring engines.node, .nvmrc, .python-version or the go directive in go.mod is the cheap fix. A Dockerfile is the certain one.

Build type is separate

How an image is built is not how an application serves traffic, so the two are recorded separately. How it is built is something you pass, never something aidrop.it reads out of your code.

• build_type: nixpacks is the default. The build is inferred and the Dockerfile is generated; your repository needs none.
• build_type: dockerfile builds your own, and build_dockerfile_path says which file that is: Dockerfile, or build/Dockerfile.api in a monorepo. The file may be anywhere in the repository. The repository root is always the build context, so COPY paths resolve from the root. A Dockerfile nobody named is never opened: committing one changes nothing until a build names it.

A build reads the Service’s recorded settings and nothing else.

A Dockerfile does not change the runtime kind. A Python service built from its own Dockerfile is still python_http; container is the kind for an image that already knows how to run itself.

A repository nothing on this page describes is still deployable. Name build_type: dockerfile, the port and the health path. The image knows how to build and run itself, and that is all aidrop.it was missing.

What the build records

service_build records the settings it built under, and service_get reads them back as runtime_settings:

• runtime_kind: how the application serves traffic; container when the Dockerfile decides everything.
• container_port and health_path: the two the first build asks for.
• resource_class: the size, defaulting to the smallest the plan includes.
• build_type: nixpacks (the default) or dockerfile, with build_dockerfile_path when it is dockerfile. Passed, never detected.
• required_secret_names: the names of the Project’s secret values this Service reads. Only the values it names reach it. The values are stored on the Project, only by an agent with project_secret_set, and no read answers one back. The dashboard lists the names, never the values. A build is refused while a named value has none.

There is no preflight check. aidrop.it runs no analyser over your code. When a build stops, it names what stopped it.

Sizes

A resource class is the size of the box: how much CPU and memory an app gets. Every container runs inside one, and the numbers are hard limits, not targets:

dual and medium share a CPU figure on purpose. One doubles the cores, the other doubles the memory. Which you need depends on whether your application mostly waits or mostly computes. Every class caps processes at 256.

As a guide from the playbooks: a simple Streamlit dashboard fits the smallest size. Self-hosted n8n for daily use, and a scheduled web scraper that drives a headless browser, want the 1 GB compact size, which starts at Pro.

Storage is not on this table because there is none. The root filesystem is read-only. There are three small scratch folders (/tmp, /run, /var/tmp), and they are emptied on every restart. Anything that must survive belongs in a database.

What your plan includes

A plan sets two separate limits:

• Projects: how many products you may run. A Project is one product, with everything inside it.
• The pot: the plan’s shared memory and CPU. Everything inside your Projects draws from it.

Prices are in US dollars. Scale adds human support. The current prices are on the aidrop.it pricing page. Without the trial or a paid plan, nothing runs. Sign up to start the trial.

From Pro, a Team may also choose how big its database is: micro or compact on Pro, plus dual on Scale, plus large on Business. The size is memory and CPU out of the same pot. It can be changed on a running database, which restarts it, so apps reconnect. Going back down is offered too; a smaller size never takes disk away from a database that is using it.

Two things follow from the pot that the size list does not tell you:

• A size your plan lists still has to fit. Pro lists dual at 2 GB and has 3 GB in total, so one dual app leaves room for a database and nothing else.
• A stopped application still holds its share. The pot counts what is reserved, not what is running, so the numbers you see never promise room that the next deploy would refuse.

Business runs on a cluster of its own rather than the shared one.

Databases, caches and queues

A backing service is a database, cache or queue that aidrop.it runs beside your application. You do not install or configure one; your agent asks for it, and its connection string arrives as an environment variable at deploy.

These are deliberately smaller than any application size. A tuned PostgreSQL serving one small app needs far less than the app in front of it, and each one shares a server with the traffic router. The size is memory and CPU, not disk. How much data you keep is not separately capped. A cache or a queue is not file storage for your app either.

aidrop.it takes daily snapshots. You can also take an independent export whenever you want one, and exporting your code and database shows how your agent does it.

The queue is Valkey as well, and speaks redis://. The two Valkey services differ in the way that matters for what you put in them. The cache evicts old keys when it is full. The queue refuses the write, because work thrown away in silence is worse than a producer that finds out. The queue keeps an append-only log on a volume of its own; the cache keeps nothing.

The cache is Valkey, an open-source fork of Redis. The redis:// scheme is unchanged, so every Redis client library connects to it as before.

Each variable names the role, not the product. It is CACHE_URL and QUEUE_URL rather than REDIS_URL, the way DATABASE_URL has always worked. Your code says what it needs the connection for, and stays correct if what runs behind it ever changes.

A backing service is the Project’s, one per kind per Project. Any Service in the Project can be attached to it, and each reads the same variable. Inside one PostgreSQL you can create separate databases and attach each to a different Service. Several Services then share one claim on the pot while keeping their data apart.

Never hard-code a connection string. Read the variable: it is what makes the same code work whether the service was created for this Service or already existed. The MCP tool reference lists the calls that create, attach and resize these services.

Changing the settings

Pass the value to service_build again:

{
  "service_id": "…",
  "resource_class": "medium",
  "required_secret_names": ["DATABASE_URL", "SMTP_PASSWORD"]
}

Every setting not passed is kept from the previous build. Settings are never rewritten in place: a changed value is recorded as a new set, tied to the commit being built, and the size limits are copied in at that moment. A later change to this page’s tables never alters a build that already ran.