Get a shareable link for what Hermes Agent makes

No. host0 doesn't run agents or any long-lived process. It serves what an agent produces: pages, apps with shared data, PDFs and other files.

If you searched for somewhere to run the agent, these are the options Hermes's docs name:

• A machine of your own or a cheap VPS, reached over Telegram or another gateway.
• Serverless backends like Daytona and Modal, where the environment hibernates when idle.
• Hermes Cloud from Nous Research, which runs hosted instances that you manage from Nous Portal.

None of them replace host0, or the other way round. Hermes runs on one of those, and what it makes goes on a link here.

When the result has to outlive the chat or reach people outside it. For one chart or PDF going to people already in the conversation, Hermes's Deliverable Mode is the better choice, and you don't need host0.

Say which one you want, since Hermes's docs note it doesn't reach for attachments unprompted. If the reply mentions a file's absolute path as plain text, the gateway uploads that file, so "send me the link, not the file" is worth saying.

You can, and if the app needs real server code, that's the way today, because host0 only serves static files plus its own records API. For everything else, a link is less to look after.

• On your VPS, the domain, certificate, firewall and uptime are yours to run. Hermes can start a server in the background, but the page then shares a machine with an agent that has a terminal.
• On a Daytona or Modal backend, the environment hibernates when idle, and anything it was serving goes quiet with it.
• On host0 there's no process to keep alive. The files upload once, and the URL keeps working with Hermes switched off.

Hermes posts a link and a short code in the chat, you approve them in your phone's browser, and it carries on. You never put a key or an email address into the conversation.

That suits how Hermes treats secrets, since its messaging surfaces won't collect them in chat either. The code lasts 10 minutes, and each run waits about 90 seconds for you, so if you're slower than that, just ask Hermes to check again. We haven't run this over a gateway, though nothing in the flow depends on which app you're in.

In ~/.host0/credentials on whatever the terminal tool runs on, which often isn't where Hermes itself runs. That decides how often you sign in, and which account publishes.

To sign in only once, copy the key by hand from a ~/.host0/credentials you already have, never through the chat, into HOST0_API_KEY in ~/.hermes/.env, and list that name under terminal.env_passthrough. The host0 skill doesn't declare that variable, so Hermes won't forward it by itself, and Docker and SSH pass no host variables by default. SSH also needs a matching AcceptEnv on the server.

If you've locked down outbound traffic from Docker, allow host0.ai and host0.app, plus registry.npmjs.org for the CLI.

It shouldn't. A deploy doesn't match anything on Hermes's list of dangerous commands, and that check is skipped altogether on container backends such as Docker and Modal.

• Two things in this flow can trip it. Piping our one-line installer into a shell is on the list, which is why this page points you at hermes skills install. So is wrapping a command in bash -c.
• If you do get a prompt in a chat, reply yes or no. An unanswered one is denied after the timeout, 300 seconds by default.
• A big upload is a likelier stop. terminal.timeout is 180 seconds in the docs' sample config, so raise it if a deploy of large files gets cut off.

We don't know about the scanner yet, since we haven't run it, and yes, Hermes can change it. A skill from a well-known endpoint installs at community trust, and by default the agent writes to skills freely.

• The scan looks for things like data exfiltration and destructive commands, and our skill does talk about API keys and uploads. A caution-level block can be overridden with --force once you've read the skill. A dangerous verdict can't, so write to support@host0.ai if you hit one, and use the CLI route meanwhile.
• After a turn, Hermes's background review can patch a skill it learned something from. That can help, but hermes skills update then skips the skill as locally edited, so you stop getting our changes until you pass --force.
• To see every edit first, set skills.write_approval: true, and proposed changes wait for you under /skills pending.

It should: attach the skill to the job, and each run publishes a new version to one URL. We haven't run this one either. Sign in from a normal chat first, because a cron run has no chat attached where you could approve a login.

You can set it up by asking: "Every weekday at 8, rebuild the report in ~/reports/sales and publish it with the host0 skill to the app sales-report, then send me the link on Telegram."

• Name the folder and the app in the prompt. Each job starts in a fresh session and remembers nothing else.
• Check that the terminal toolset is on for the cron platform in hermes tools. Cron jobs get that set, not your CLI's.
• Decide who reads it. A private report needs each reader invited once, while a link anyone can open needs nothing further.
• A dangerous command in a cron run is denied rather than asked about, under the default cron_mode.

If the reader only needs a few lines of text each morning, Hermes's own delivery to Telegram or Slack is simpler and needs no host0 at all. Publishing earns its place when the output is a page, a chart people revisit, or something for people outside that chat.

The account whose key is on that machine. Everyone you let talk to the gateway can publish, rename and delete as that account, so treat the gateway's allowlist as access to your host0 apps too.

• Hermes's admin and regular-user tiers gate slash commands today. Plain chat isn't affected, so a regular user can still ask for a deploy.
• A Bot in Bot Mode is a profile, and skills are per profile, so install the skill once per Bot with hermes -p <bot> in front.
• On a host install, profiles share your real home, so every Bot publishes to one host0 account unless you set terminal.home_mode: profile.

The people who open what's published need none of this. They use a browser, and a private app asks them to sign in with the email you invited.

Name the app by the slug in its URL. The first deploy notes the app in .host0/state.json in that folder, so that folder keeps updating one URL, but a new scratch folder would create a second app.

Hermes has memory across sessions, so tell it once: "remember that the team board is the host0 app team-todo". If the files aren't on that backend any more, the skill can pull the live version, edit it and publish it back at the same URL.

Mostly. Hermes's import-agent command copies skills and MCP servers from Claude Code, Codex CLI and Cursor, but it never copies credentials.

The skill arrives under a folder like ~/.hermes/skills/claude-code-imports/, and you'll need to sign in to the MCP server again. On a local backend, ~/.host0/credentials is already where the skill looks, so publishing should need no new login. We haven't tried this import ourselves, and it needs Hermes's agent-importers plugin.