Your agent/Codex

Codex wrote it.
Give it somewhere to put it.

One command adds agenthost to the config the CLI, the app and the IDE extension all share. From then on, deploying is something Codex does rather than something you do after it.

The work is done. It just is not anywhere.

Codex is happy to work on something for a long time and hand back a finished branch. The part that does not fit that shape is the deploy, because deploying usually means a console, a project wizard and a handful of questions only you can answer.

agenthost removes the questions. There is no build command, no framework preset and no port setting, so there is nothing left for Codex to stop and ask you about. It sends the files, we work out what they are from what is inside them, and the answer is an address.

Because the connection lives in ~/.codex/config.toml, it is the same in the terminal, in the app and in the IDE extension. Sign in once and whichever surface you are using that day can deploy, read the logs of the running app, and put the previous version back when a change turns out to be wrong.

You ask for it in a sentence.

There are no commands to learn on our side. These are whole sentences, typed the way you would say them to a person, and each one is a thing agenthost does.

ship it

Uploads the project, works out the runtime, and answers with a working https link. No project to create first.

deploy the branch on github instead

Links the repo and deploys from a branch, so the next push is a sentence rather than a pipeline.

it's returning 500, read the logs

Pulls the running app’s logs, finds the trace, and can fix and redeploy in one turn.

give it a database

Creates one, attaches it, and sets the environment variable the app reads it from.

roll back

Every deploy keeps the one before it, so this is a sentence rather than an incident.

There is more of this in the how-to guides, which are written for your agent to read as much as for you.

Whatever it built, it can publish.

You do not have to know what it is made of. Your agent works that out and tells us.

  • framework preset
  • build command
  • output directory
  • install command
  • API keys
  • credit card
  • region

Nothing here can stop and ask you a question.

Every one of these is a setting some other host would demand before it would take your files. None of them exists here, which is why your agent can go from a folder to a working link without checking in.

  • Dockerfiles
  • port settings
  • TLS certificates
  • DNS records
  • CI pipelines
  • health checks
  • scaling rules

The one thing agenthost does expect is an entrypoint per runtime, and the deploy reference is where Codex reads it before the first deploy.

How it connects.

Two commands. The first writes agenthost into ~/.codex/config.toml, the second opens your browser to sign in.

codex mcp add agenthost --url https://agenthost.eu/mcp
codex mcp login agenthost
1

Add the server

Passing a URL rather than a command tells Codex this is a streamable HTTP server. It is written to the config file the CLI, the app and the IDE extension all read.

2

Sign in with your email

codex mcp login opens your browser. You type the code we email you and approve the connection, and Codex keeps the token in your system keychain.

3

Ask for a link

Say ship it, or put this online. If you are new to agenthost, that first deploy is also what creates your account.

There is no key to paste, and nothing is written outside your own Codex config. The get started page walks through all of it, with the buttons and the sign-in step.

The usual ones.

Codex added it but the tools never show up.

On older Codex versions, remote HTTP servers need the rmcp client turned on. Add a [features] block with experimental_use_rmcp_client = true to ~/.codex/config.toml, above the server entries, or upgrade Codex and it is on by default.

Does this work in the Codex app and the IDE extension too?

Yes, and you only do it once. All three read the same ~/.codex/config.toml, so the server you add in the terminal is there in the app and in the editor.

What about a run with no browser, like CI?

Sign in once as yourself on a machine that has a browser, then ask for an API token and give that to the unattended run. Tokens are long-lived and sent as a bearer header.

Deploy from CI or an unattended agent →

Will it deploy things I did not mean to deploy?

Nothing goes out without you asking for it. Deploying is a tool call like any other, so you see it happen, and taking something down again is one more sentence.

Is there an API key to paste anywhere?

No. agenthost signs you in through your browser, and your agent never sees a password or a key. There is nothing to copy out of one window and into another, and nothing to rotate later.

What does it cost to try?

Nothing, and there is no card. Your first ten websites are free and stay free. You only pay when the thing you built has to run code on our side, or when you want it on your own domain.

What it costs →

Can I connect more than one agent to the same account?

Yes, as many as you like. They all see the same projects, so you can build something in one and update it from another. Connecting the second one is a single click, because your browser is already signed in.

Where is this actually hosted?

In the EU, by a European company. Your files, your database and your logs stay here, and so does the billing.

Not what you use?

agenthost is a standard remote MCP server, so anything that speaks MCP can drive it. These are the ones with a page of their own.

Point Codex at it.

Two commands to connect, no card, and the branch you just finished gets an address.