Skip to main content

Story: deploy an agent from the console, no terminal

This build never leaves your browser. You will take an empty project to a published, key-protected agent that can run Python — without installing the CLI, without opening a terminal, without writing a config file. Budget about 15 minutes.

The point is not that the console is the best way. The point is that it is a complete way: everything the CLI does, the console does too. If you are evaluating the platform, this is the shortest path from nothing to something you can show someone.

The shape of the thing

Three console pages do all the work: Project Settings (the mapping), Compute → Agents (the deploy and the chat), and the agent's Endpoints section (the publish and the key).

Before you begin

  • A platform account that can sign in at https://console.codyhill.dev — created by an admin or an invitation link. See create an account.
  • The admin role on a project. Saving the project's Crusoe Cloud credential is an admin action.
  • A Crusoe Cloud access key ID and secret key, created in Crusoe Cloud. The platform never mints one.
  • A model API key saved for the project — agent deploys are refused without one. Check Project Settings: if there is already an inference key saved, you are done.

Step 1: connect the project to Crusoe Cloud

Everything you deploy is built into a container image, and the image is pushed to a repository in your own Crusoe Cloud registry. A project with no credential cannot deploy anything — the refusal happens up front, not halfway through a build.

  1. Open your project and go to Project Settings.
  2. Click Map to Crusoe Cloud.
  3. Paste the access key ID and the secret key. If your key can see more than one Crusoe Cloud project, a picker appears after the first submit — choose one and submit again.
  4. Click Map project.

The dialog tells you what happens to the secret key: it is validated once, stored, and never given back. No read on this platform — not the API, not a platform admin — ever returns it.

Already mapped? The page says so, and this step costs you nothing.

Step 2: deploy the agent

Go to Compute → Agents → Deploy agent. The dialog offers three ways to provide code; choose the in-browser editor.

One file, named agent.py, with this in it:

def get_word_length(text: str) -> str:
"""Return the number of characters in the given text."""
return str(len(text))

That function is a tool: a Python function the agent may decide to call. No schema to author, no separate wiring — a docstring telling the model what it does is the whole description. Name the agent letter-counter and deploy.

The build takes a minute or two. If it fails, the agent's page shows the tail of the real build output — the actual pip error or syntax error — not a generic failure badge.

Step 3: chat with it

Still in the console. Open the agent and use the chat panel:

How many letters are in "antidisestablishmentarianism"?

Watch two things:

  • The agent calls your get_word_length tool instead of counting in its head — the turn shows the tool call.
  • Ask a follow-up like "and in the German word for it?" — the second answer works because the platform replays the conversation history to the model each turn. That is sessions, and it comes with every agent. There is nothing to enable.

Step 4: publish it for someone else

Your agent is private by default — reachable only through the signed-in control plane. A colleague's script cannot call it until you deliberately publish.

  1. On the agent's page, open the Endpoints section.
  2. Click Publish endpoint. Leave the suggested name.
  3. When it asks how to protect the endpoint, choose API key.

Choosing API key matters because of the rule the Gateway keeps: it fails closed. If the protection you asked for cannot be put in place — say, an endpoint that checks keys but holds none — the endpoint does not serve. It goes down with the reason, rather than answering anonymously. So the publish flow issues the first key. Copy it: it is shown exactly once.

The address looks like https://letter-counter-ab12cd.apps.codyhill.dev. Your colleague calls it with one header:

curl -X POST "https://letter-counter-ab12cd.apps.codyhill.dev/v1/agents/letter-counter/invoke" \
-H "X-API-Key: <the-key-you-copied>" \
-H "Content-Type: application/json" \
-d '{"message": "how many letters in \"pneumonia\"?"}'

You should see a JSON answer with an output field.

Step 5: prove the key matters

Call it again without the header and the request is refused at the door — your agent never sees it, and your logs stay clean. Revoke the key in the same Endpoints section and the same thing happens to every caller holding it.

Then unpublish. The address stays reserved, the settings survive, the agent keeps running — but the address is off the internet until you publish again. That distinction — endpoint exists versus endpoint is serving — is the whole security model in one pair of states. See Gateway overview.

What you just used, and where to read more

You usedThe page that documents it
Crusoe Cloud mappingCrusoe Cloud integration
Agent deploy and toolsDeploy an agent, Tools
Conversation continuitySessions
Publishing and protectionPublish an endpoint, Authentication
Revocation and revision historyTraffic and revisions

The natural next story is doing the same thing with more room to move: deploy an API from the CLI.