Managing Env Vars and Cron Jobs From the Terminal, For You and Your Agents

Two of the most common reasons developers open a deployment dashboard are updating environment variables and scheduling cron jobs. Both are tiny, everyday tasks. Both somehow require clicking through a dozen screens on most platforms. Both are also tasks AI agents need to perform on your behalf, and agents don't do well with "paste this into a web form."

This post shows you how to manage both, end to end, from a terminal (or from an AI agent that calls the same commands over MCP). We'll use the CreateOS CLI. Everything here is shipped, verified, and works the same whether a human types it or an agent calls the equivalent MCP tool at https://api-createos.nodeops.network/mcp.

Why this matters for agents

If you're building with Claude Code, Cursor, or any other MCP-compatible AI assistant, you've probably hit this: the agent deploys an API successfully, then stalls because it can't add DATABASE_URL without human intervention. Or you ask it to "set up a nightly cleanup job" and it has no primitive to call.

CreateOS exposes env var management and cron job scheduling as MCP tools. The agent has 75+ of them available. Everything in this post has an agent-equivalent, which means your workflows stop hitting dead ends.

Prerequisites

• CreateOS CLI installed (brew tap nodeops-app/tap && brew install createos)
• A project linked with createos init
• For agent use: the MCP server added to your client (Claude Code setup)

Part 1: Environment variables

List what's there

createos env list

Shows everything currently set in your project's environment. Values are displayed in full by default, which is what you want when you're debugging. To mask them:

createos env list --hide

For scripts and agents, emit structured JSON:

createos env list -o json

Set a single variable, or many at once

# One
createos env set DATABASE_URL=postgres://user:pass@host:5432/mydb

# Many
createos env set \
  API_KEY=sk_live_xxx \
  SECRET=abc123 \
  NODE_ENV=production

No dashboard. No "click save." The change is live on the next deploy.

Remove a variable

createos env rm API_KEY

Sync with your local .env file

Most teams keep a local .env.<environment> file for development. The CLI reads and writes this format directly:

# Pull remote vars into a local .env.<environment-name> file
createos env pull

# Push a local file up to the remote environment
createos env push

env push shows you a diff of what will change and asks for confirmation. Use --force in CI to skip the prompt:

createos env push --force

You can also specify a custom file:

createos env pull --file .env.local
createos env push --file .env.staging

This is the workflow you actually want: edit a file in your editor, commit to git if you want, push when ready. No copy-paste ceremony.

Multi-environment projects

CreateOS projects can have multiple environments (production, staging, preview). Pass them explicitly when you need to:

createos env set FEATURE_FLAG=true --project <project-id> --environment <env-id>

In interactive mode, createos env list and friends will prompt you to pick if you don't specify.

The agent flow for env vars

An agent doing the same thing via MCP calls UpdateProjectEnvironmentEnvironmentVariables (yes, that's really the name) with a JSON payload. The agent sees the current state via ListProjectEnvironments, constructs the update, and applies it. No clicking. No pasting. Inside your conversation.

User: add these env vars from my local .env.production to my CreateOS project
Agent: [calls the MCP tool, diffs, confirms, applies]
Agent: done. 4 variables added, 2 updated. Next deploy will use them.

If you've wired up the MCP server, the agent can do this mid-sentence without asking you to context-switch.

Part 2: Cron jobs

CreateOS cron jobs are HTTP-based. You give the platform a schedule and an HTTP endpoint on your deployed service, and CreateOS hits that endpoint on the schedule you define. This is the right model for production: your cron logic lives in your app, gets the same deploys and rollbacks, and stays testable.

Create a cron job interactively

createos cronjobs create

The CLI walks you through naming, schedule (standard cron syntax), HTTP path, and method. Useful when you're exploring.

Create non-interactively (CI, scripts, agents)

createos cronjobs create \
  --name "nightly-cleanup" \
  --schedule "0 0 * * *" \
  --path /api/cleanup \
  --method POST

Breakdown:

• --name is how it appears in lists.
• --schedule is a standard cron expression. 0 0 * * * runs at midnight UTC.
• --path is the route on your deployed service the scheduler will hit.
• --method is the HTTP verb. Most cleanup jobs are POST.

If your endpoint needs a body, add --body:

createos cronjobs create \
  --name "daily-report" \
  --schedule "0 9 * * *" \
  --path /api/reports/daily \
  --method POST \
  --body '{"type": "summary"}'

Before you create the cron, make sure the endpoint exists

This is where people get tripped up. A cron job is just a scheduled HTTP call. It assumes your deployed service has the endpoint ready:

// in your deployed API
app.post("/api/cleanup", (req, res) => {
  // do cleanup
  res.json({ ok: true });
});

If the endpoint returns a non-2xx status, CreateOS marks the run as failed and you can see it in the job's activity log.

List, inspect, manage

# All cron jobs for the project
createos cronjobs list

# Details of a specific job (schedule, last run, next run, recent activity)
createos cronjobs get

# Suspend without deleting
createos cronjobs suspend

# Resume
createos cronjobs unsuspend

# Delete
createos cronjobs delete

Every command works interactively or takes explicit IDs for scripting.

Seeing the run history

createos cronjobs activities

This shows a log of recent runs, with HTTP status codes and timing. When a job is misbehaving, this is the first place to look.

Agent flow for cron jobs

Via MCP, an agent can:

1. Inspect your deployed service and detect which routes look cron-worthy.
2. Propose a schedule.
3. Create the cron job after confirmation.
4. Report back with the cron ID and next run time.

This is a dramatically better UX than "open the dashboard, click cron jobs, click add, fill in the form, click save."

Why HTTP cron, not shell cron

Some platforms let you schedule shell commands ("run node cleanup.js every hour"). CreateOS doesn't. That's deliberate. HTTP cron is:

• Testable. You can curl the endpoint locally and in staging, no scheduler involved.
• Versioned. The cron logic is code that ships with your deploy. A rollback rolls it back.
• Observable. Requests show up in your normal logs, metrics, and traces.
• Idempotent by design. If a run fails or retries, your handler is already the right place to handle it.
• Portable. Every platform speaks HTTP. None of them speak your framework's idea of "a cron script."

If you want to run arbitrary shell commands on a schedule, that's what a worker service or a VM is for. For cleanup tasks, report generation, cache warming, webhook-style recurring calls, HTTP cron is the right primitive.

Putting it together: env vars plus cron in a deploy script

Here's a real bash snippet you can drop into CI:

#!/usr/bin/env bash
set -euo pipefail

createos login --token  # reads $CREATEOS_TOKEN from env

# Sync secrets from our secrets manager
./scripts/pull-secrets > .env.production
createos env push --force

# Deploy
createos deploy --project "$CREATEOS_PROJECT_ID"

# Ensure the nightly cleanup cron exists (idempotent with suspend/unsuspend)
createos cronjobs unsuspend --name "nightly-cleanup" || \
  createos cronjobs create \
    --name "nightly-cleanup" \
    --schedule "0 0 * * *" \
    --path /api/cleanup \
    --method POST

Three primitives. No dashboard. No YAML. No custom orchestrator.

Using these from an MCP agent

If you've added the CreateOS MCP server to your AI client:

claude mcp add createos-mcp \
  --transport http \
  https://api-createos.nodeops.network/mcp \
  --header "X-API-Key: YOUR_CREATEOS_API_KEY"

Then natural-language requests like these just work:

• "Set STRIPE_KEY to the value of $STRIPE_SECRET_KEY on my CreateOS project."
• "Sync my local .env.production to CreateOS. Show me the diff first."
• "Create a cron job that hits /api/refresh-cache every 15 minutes."
• "Suspend all cron jobs on the staging environment."

The agent calls the MCP tools, confirms the destructive bits, and reports back. You stay in your editor.

Try it

# Install (macOS or Linux)
brew tap nodeops-app/tap
brew install createos

# Authenticate
createos login

# Link your project
cd your-app/
createos init

# Env vars
createos env list
createos env push

# Cron jobs
createos cronjobs create \
  --name "health-check" \
  --schedule "*/5 * * * *" \
  --path /health \
  --method GET

Both flows compose with whatever else you already do in a shell: pipes, scripts, Makefiles, CI, and AI agents.

---

Previous: Deploy an API in 2 Minutes →

Next: Building a Monetized API: From Zero to Earning in 5 Minutes →

Try it: Install the CLI · Env docs · Cron docs · MCP server