deploy-platform
Skill5 starsChanged 2 days agoApache-2.0View on GitHub
Prepare a GitHub repository, deploy AgentOS through a Render Blueprint, configure authentication, and verify the live application. Use for first deployment, redeployment, or production configuration changes.
- Reads credentials
We split this skill into the rules it gives an agent
7 rules. 0 are common, 4 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 10
Read AGENTS.md, render.yaml, and the application's settings.
- Distinctive: line 11
Use the current Render Blueprint docs when dashboard details are uncertain.
- Distinctive: line 19
Use a private repository unless the user wants it public.
- Distinctive: line 40
Wait for the API to become live and copy its public HTTPS URL.
- Very specific: line 42
Start with the Blueprint's one always-on API instance with 1 CPU and 2 GB RAM (1c-2g) and PostgreSQL 18 database.
- Very specific: line 81
If MCP is configured, an unauthenticated initialization POST rejects access and the intended client connects with authentication.
- Distinctive: line 104
When requested, follow sandboxes for hosted coding agent execution and durable checkpoints, or scaling for replicas.
“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Deploy the Platform on Render
Help the user deploy their application through the Render dashboard. Prepare the
repository, guide the Blueprint setup, and verify the authenticated application.
Read AGENTS.md, render.yaml, and the application's settings.
Use the current Render Blueprint docs
when dashboard details are uncertain.
1. Prepare the GitHub repository
Inspect the Git remotes, branch, and application changes. Reuse the user's repository
if one exists. Otherwise, establish the GitHub owner, repository name, and visibility,
then help create it using the available GitHub integration or gh repo create.
Use a private repository unless the user wants it public.
Preserve the template remote as upstream when making the user's repository
origin. Review the files to publish, exclude credentials and local artifacts,
commit the application, and push the intended deployment branch. Verify that the
pushed branch includes the user's agents, Dockerfile, and root render.yaml.
Help the user grant Render's GitHub connection access to this repository.
The Blueprint creates an AgentOS project and Production environment.
Set projects[0].name to the user's application name before pushing if they want
a different project name.
2. Deploy the Blueprint
Identify the intended Render workspace and any existing deployment. Reuse its Blueprint, API service, and database when present; continue to configuration below. For a new deployment, guide the user through Render:
- Choose New → Blueprint and connect their GitHub repository.
- Select the deployment branch and root
render.yaml. - Enter
OPENAI_API_KEYand setRUNTIME_ENVtodevfor initial setup. - Review the resources and billing, then choose Deploy Blueprint.
- Wait for the API to become live and copy its public HTTPS URL.
Start with the Blueprint's one always-on API instance with 1 CPU and 2 GB RAM
(1c-2g) and PostgreSQL 18 database.
Confirm both use Virginia (region: virginia) before deploying.
Preserve the database references. Initial setup runs without authentication;
continue directly to securing the application below. For an existing secured
deployment, keep RUNTIME_ENV=prd.
3. Configure access
At os.agno.com, create a Live connection using the Render URL. In Settings → OS Security, enable Token-Based Authorization (JWT) and copy the public verification key.
In the Render API service's Environment settings, configure:
| Variable | Value |
AGENTOS_URL | Public HTTPS service URL, without a trailing slash; used by scheduling and MCP OAuth. |
JWT_VERIFICATION_KEY | Complete public PEM, with real line breaks and no surrounding quotes. |
RUNTIME_ENV | prd, set together with the verification key to enable production authorization. |
| Model and integration credentials | Values required by the configured agents, such as ANTHROPIC_API_KEY for Claude Engineer. |
Have the user enter secrets directly in Render. Preserve existing working settings,
including JWT_JWKS_FILE when used for verification. Choose Save, rebuild, and deploy,
inspect startup logs, and verify the AgentOS connection once the API is healthy.
RUNTIME_ENV uses sync: false, so later Blueprint syncs preserve its dashboard value.
For browser MCP access, set MCP_CONNECT_SECRET to a securely generated random
secret, save and deploy, then connect the client to <AGENTOS_URL>/mcp. The user
enters that secret on the consent page. Preserve an existing secret during updates
and never print credentials. Coding clients can use uvx agno connect --url <AGENTOS_URL>.
4. Verify the application
Complete setup only after the production redeploy passes these checks:
RUNTIME_ENV=prdis deployed,/healthsucceeds, and/docsloads./agentsrejects unauthenticated requests; an authenticated request succeeds within the user's permissions, and the AgentOS UI connects.- If MCP is configured, an unauthenticated initialization POST rejects access and
the intended client connects with authentication. A plain
GET /mcpis not an auth test.
Production has its own database. Ingest any required documents there before testing knowledge-dependent agents. Claim success only for behavior actually verified.
5. Confirm the project and hand over
Open the project created by the Blueprint and verify that its Production environment contains both the API service and PostgreSQL database. The Blueprint manages the project, environment, and resources together.
Hand over the live URL, project/environment, Blueprint link, and verification results so the user knows where to manage the application.
Updating the application
Push code to the connected branch and check the resulting deploy. If auto-deploy
is disabled, choose Manual Deploy → Deploy latest commit. Edit production
settings in Environment and save and deploy. Keep infrastructure changes in
render.yaml; Blueprint sync can overwrite conflicting dashboard settings.
Preserve the database and saved application state during updates.
When requested, follow sandboxes for hosted coding agent execution and durable checkpoints, or scaling for replicas.
Other versions4 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 4
- agno-agi/agentos-railway★ 41same name
- agno-agi/agentos-docker★ 14same name
- agno-agi/agentos-fly★ 4same name
- agno-agi/agentos-helm★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository7 other files it gives its agents.
- AGENTS.mdAGENTS.md
- create-agentSkill
- create-evalsSkill
- extend-agentSkill
- improveSkill
- review-and-improveSkill
- setup-platformSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

