How Fileaify ships Fileaify, with production keys the agent never sees

Fileaify runs on a server that needs an SSH key to change. We did not want that key in a conversation, on the agent's machine or in a model's context. We also did not want to re-explain the deployment each time a new conversation started.

So Fileaify ships with Fileaify. This is the method, taken from the procedure the agent actually follows.

A new conversation starts from the documentation

A deployment does not begin with a long briefing. The agent connects to the Fileaify project and reads its contract, its charter and the documents the task calls for. For a release, that means the current state of the product and the deployment procedure.

That procedure states the steps, what must never be touched and how to roll back. It also records the release currently in production, so the agent knows its starting point.

The agent names a destination. It does not get a key.

The project's documentation lists the servers the executor may reach. Each row gives the destination and refers to a key in the vault by name, in the form vault://service/key-name. The value is not in the document.

To run a command on that server, the agent calls executor_ssh_run with the name of the destination and the command. The executor uses the key on its side and returns the output with known secret values redacted. The agent sees the result without ever having held the key.

A person decides

Reading the documentation grants nothing. The agent has to request executor.run and the use of that specific key, and the owner approves or refuses in Fileaify. Grants have limits, so a later session may have to ask again.

The owner also decides when a release goes out. Green tests do not put anything into production by themselves.

What the release looks like

The agent runs the full test suite and pushes the commit. It then produces the difference with the release in production and sends it through the executor. A single script, detached from the terminal, does the rest:

1. It verifies the fingerprint of the change it received.
2. It copies the previous release and applies the change to the copy, starting with a dry run.
3. It compiles the code and validates the translation files.
4. If the database schema changes, it first runs the migration on a copy of the production database.
5. It takes a backup, then switches to the new release and restarts only this service.
6. It waits for the health check, and rolls back automatically if the check fails.

The script is detached because a release can restart the very service the agent is using to deploy. The work has to finish without it.

The next conversation inherits the result

After the release, the agent checks from outside that the service answers and that the deployed files match the commit. It then proposes the documentation update: which release is live, what was checked and how to go back.

That update is what makes the next deployment simple, because the next conversation reads it instead of relying on someone's memory.

What this does not protect against

Keeping the key away from the agent solves one problem, and it would be misleading to present it as more than that.

• An approved command is still powerful. While it holds the grants, the agent can run commands on that server with that key's rights. The key is hidden, but its power is not reduced.
• Redaction is a safety net. It catches known values in the output. It is not a boundary against a command written to leak a secret.
• Approval is not review. Approving a grant allows a scope of work. It does not mean a person read each command.
• The account matters. A key restricted to deployment limits what a bad command can do, and hiding a key is no substitute for restricting it.

Do this on your own project

The method does not require Fileaify: a written procedure, a key held outside the conversation, a human go-ahead, a script that can roll itself back and a record of what happened. Fileaify puts these pieces in one place, for the agent you already use.

If you want to see the flow first, the demo runs it on a prepared project. The exact rules are in the executor reference.