# spredr documentation Every page of https://spredr.cloud/docs, in Markdown. The index, one line per page: https://spredr.cloud/llms.txt --- # What spredr is spredr is an orchestrator for your backends: it takes your code, builds it, runs it on machines from different providers and keeps it up even when one of them falls. You publish; spredr decides where it runs. what you can publish ## Any service that runs in a container Each api, site or worker you deploy is a service. If your repo has a Dockerfile, spredr uses yours; if not, it detects your language and builds the image. APIs and sites They answer on their own address with https, or on your domain. Workers Bots, agents and queue consumers: they run with no public address. From your repo GitHub or GitLab: every push to the branch publishes a new release. From your terminal Publishing, watching and configuring, all from the CLI; with --json a script or an agent drives it. what spredr does for you ## What you don't have to run building: It clones your commit, builds the image and signs it. running: Each service in its own box, with a memory and CPU limit. publishing: https on your address and on your domains, through Cloudflare. switching releases: The new release takes over when it answers on its health path; if not, the previous one stays. rescuing: If a machine falls, your services move to another on their own. watching: Logs, memory, CPU, traffic and risks, live. --- # Your first deploy From a GitHub repo to a live address. Before the terminal you need two things: a spredr account and the spredr app on your GitHub. After that, all of it happens in the terminal. ## Get an account Everything starts with a spredr account: your services, your plan and your tokens live there. [Create my account](https://spredr.cloud/signup) ## Connect GitHub spredr builds from your repo, so it needs to read it. In your account, under Connections, install the spredr app on GitHub and pick the repos you want to publish. [Open Connections](https://spredr.cloud/account/connections) ## Install the CLI One file, for you only, no sudo. Before installing, the installer checks its sha256. ```sh $ curl -fsSL https://spredr.cloud/install | sh ``` On Windows, the PowerShell installer is on the command line page. ## Connect your terminal A page opens where you check the code, choose what this terminal may do and for how long, and approve it. You never paste a token. ```sh $ spredr login ``` ## Create the service from your repo Tell it the port your app listens on and a path that answers 200 when it is ready. With --deploy it publishes right away and shows you the build as it happens. ```sh $ spredr new tu-usuario/mi-api --port 8080 --health /health --deploy ``` With no Dockerfile, spredr detects your language and builds the image. With one, it uses yours. ## Watch it live Memory, requests, latency, errors and its logs on one screen. q to quit. ```sh $ spredr live $ spredr logs -f ``` ## Publish on your domain It already answers on mi-api.onspredr.com. To use yours, prove it is yours with a TXT record and choose which one answers. ```sh $ spredr domains add api.tudominio.com $ spredr domains verify api.tudominio.com $ spredr domains use api.tudominio.com ``` --- # How your service runs You publish your code; spredr builds it, runs it and puts it in reach of your customers with https. This is what happens on the way and what it guarantees you. Your customers come in only over https. The machines have no other open door. for you ## What this guarantees you only yours runs: A machine starts only the image built from your commit. Nobody can swap it for another on the way. your secrets don't travel loose: Your variables are encrypted for the machine that runs your service. The build never sees them. no other way in: Your service gets traffic only over https, at its address or on your domain. never a broken deploy: The new release gets traffic only when it answers on its health path. If not, the previous one stays. --- # Where it runs Your service runs in the region you choose, on machines from more than one provider. You don't depend on a single one doing well. regions ## Choose close to your database There are two: the United States (us) and Europe (eu). Your service stays in its region, also when it moves. Only if there were no room there would it run in another for a while, and it comes back as soon as there is room. Put it where your database is: every query travels less. spredr suggests the region by reading your database’s address in your variables. ```sh $ spredr settings mi-api --region eu ``` providers ## More than one provider behind it Your service lives on machines paid by the month, and if one falls another from a different provider takes over. Today the base is Contabo and the backup is Google Cloud; OVH, AWS and Azure are on the way. What matters for you: if a provider has a bad day, your service keeps going on another. --- # If a machine falls You don't have to do anything. spredr notices, puts your service on another machine in the same region and it answers again in about 4 minutes. Measured on real machines: about 4 minutes from the fall until your service answers again. what you do: Nothing. spredr does it on its own. how long: About 4 minutes, measured on real machines. where: In the same region whenever there is room: your service stays close to your database. no false alarms: A minute of bad network isn't enough: spredr confirms the fall in more than one way before moving anything. what is lost: What your service held only in memory. Keep in your database what you cannot lose. --- # A deploy Every push to your service’s branch is a new release. Your customers move to it only when it is healthy: they never see a broken deploy. spredr deploy shows you each step as it happens, and ends when the release is live or has failed. you start it: With a push to the branch, or with spredr deploy for the latest commit. you follow it: spredr deploy shows you the build as it happens and waits until it is live or fails. if it fails: The previous release stays live. spredr build gives you the build log and spredr logs --stream deploy what happened at start. if you regret it: spredr rollback goes back to an earlier release in seconds, without building again. ```sh $ spredr deploy $ spredr build $ spredr logs --stream deploy $ spredr rollback v14 ``` --- # Security What spredr protects for you, with nothing for you to set up. Only what you published runs Every image is signed from your commit to the machine: nobody can swap it on the way. Your service, in its box Each service runs isolated, with its own network: another service cannot see yours. Encrypted secrets Your variables are stored encrypted and never shown in a terminal. Reading one from the panel is logged. One door only Your service is reached only over https. The machines have no other open port. Everything is logged Deploys, changes, sign-ins and refusals, in spredr activity. The log can't be edited or deleted. Everyone within limits Each service has its memory and CPU limit, and each account its traffic limit: a neighbour can't go past theirs. your terminal ## Signing in without pasting tokens spredr login opens a page where you check the code your terminal shows, choose what it may do and for how long. If the request doesn't come from your own network, the page warns you. Every session shows in Activity and spredr logout closes it on the server. --- # Configuring a service How it is built and how it runs: the branch, the folder, the Dockerfile, the start command, the port, the health path, the memory and the region. With no flags, spredr settings shows what it has. ```sh $ spredr settings $ spredr settings mi-api --memory 512 ``` --branch : The branch it follows: every push to it publishes a release. --root : The service's folder inside the repo, for a repo with several services. --dockerfile : A Dockerfile inside that folder, like Dockerfile.worker. Without one, spredr detects your language. --command : The start command, if it isn't the image's. Empty goes back to the image's. --port : The port your app listens on. --health : A path that answers 200 when it is ready. With no path, the service is a worker: healthy while its process keeps running, with no public address. --memory : Its memory limit, from 64 MB up to what your plan allows. It counts against your account's memory. --region : Where it runs: as close as possible to your database. a worker ## A bot or an agent, with no address A worker is a service with no health path. It gets no traffic: it runs its process and spredr watches it while it keeps running. It's for bots, agents and queue consumers. ```sh $ spredr settings mi-agente --root apps/agent --command 'node src/agent.ts' ``` --- # Persistent volumes A volume keeps files across deploys: an SQLite database, what your users upload, a cache. It is encrypted on its machine and backed up every 15 minutes. ```sh $ spredr volume set mi-api --size 5 $ spredr volume mi-api ``` Also from the panel (Settings › Disk) or in your spredr.json, with "volume": { "path": "/data", "maxGb": 5 } inside deploy. A spredr.json that leaves it out keeps it as it is: it never removes it. One copy: A service with a volume runs as a single copy: two cannot write to the same disk. Its machine: It stays on the machine its data is on and never moves by itself. It only goes to machines with room for all of its size. Encrypted: Each volume has its own key, sealed to its machine. It never shows in the panel or the terminal. Backups: Every 15 minutes, encrypted, off the machine. The panel tells you when the last one was and whether one failed. Size: Your plan includes some GB for all your volumes; past them, with pay as you go. If a volume holds more than its size, the panel tells you. restore ## Back to a backup Puts the volume back as it was in a backup: the latest, or the one you pick with --from. What it held is kept aside on its machine, not deleted. The service stops for a few seconds meanwhile. ```sh $ spredr volume restore mi-api --yes ``` remove ## Remove the volume Deletes its key: what it held, and its backups, can no longer be read, and the backups are deleted from storage as soon as its machine lets go of it. It asks you to type the service's name. A service with a volume is not deleted until its volume is removed. ```sh $ spredr volume rm mi-api --confirm mi-api ``` --- # Variables and secrets Your keys live encrypted in spredr, never in the repo. In the terminal you only see their names; changes apply from the next deploy. ```sh $ spredr vars $ spredr vars set DATABASE_URL=postgres://… LOG_LEVEL=info $ spredr vars unset OLD_KEY ``` importing ## From a .env file Upload every variable in a file at once, or pipe them through standard input. ```sh $ spredr vars import .env.production $ cat .env | spredr vars import - ``` names: UPPER_SNAKE_CASE, like DATABASE_URL. values: Encrypted and sealed for the machine that runs your service. Never shown in a terminal. reading one: Only from the panel, and every read shows in Activity. when they apply: From the service's next deploy. --- # Your own domains Every service answers on its onspredr.com address. To use your domain, you prove it's yours with a TXT record and point it at spredr; Cloudflare adds the https. ## Add it spredr gives you a TXT record to publish in your DNS. ```sh $ spredr domains add api.tudominio.com ``` ## Verify it spredr looks that record up. Until it finds it, the domain gets nothing: pointing it at our machines isn't enough for us to serve it. ```sh $ spredr domains verify api.tudominio.com ``` ## Point it and choose it Create a CNAME from your domain to clients.onspredr.com and choose it to answer. One address answers at a time: your domain or the service's own. ```sh $ spredr domains use api.tudominio.com ``` To go back to the service's own address: spredr domains use own how many: As many as your plan includes, across all your services. Past that, one at a time paying as you go. removing one: spredr domains rm api.tudominio.com --- # Watching Everything that happens with your services, from the terminal: their state, logs, memory and CPU, and what puts them at risk, with its fix. live ## One screen per service spredr live shows memory, requests, latency, errors and logs, refreshing every 2 seconds. Keys: p only problems, / filter, space pause, d deploys the latest commit (asks first), q quits. ```sh $ spredr live $ spredr top ``` logs ## What your service prints Three streams: runtime (what it prints), deploy (its deploys) and network (the requests it served). ```sh $ spredr logs -f $ spredr logs --problems $ spredr logs --stream network --grep 500 --verbose ``` the rest ## One command per question spredr status: How a service is doing: state, memory, CPU and traffic. spredr usage: The last 24 hours, hour by hour. spredr risks: What puts your services at risk, worst first, with the fix. spredr build: A release's build log (the latest, or -r vN). spredr activity: What happened on your account: deploys, changes, sign-ins, refusals. spredr open: Opens the service's address, or its panel page with --panel. --- # Releases and going back Every deploy is a release: v1, v2, v3. Going back to an earlier one uses its image as it is, without building again, so it takes seconds. ```sh $ spredr releases $ spredr rollback v3 ``` spredr rebuild: Builds the same commit again from scratch and deploys it. spredr stop: Turns a service off. Its releases, variables and domains stay. spredr start: Turns it back on with its last healthy release. spredr rm: Deletes a service. It asks you to type its name to confirm. --- # Your agents An agent is your code with the spredr SDK, with its own image and deployment: it takes tasks, asks before it acts, remembers and learns. You bring the model and your key; spredr brings the rest. ```sh $ npm install @spredr/sdk $ spredr new tu-usuario/shop-agent --agent shop $ spredr ask shop reply hola ``` how it works ## The life of a task Your agent is your code, in its own container. spredr brings what surrounds it: the queue, the delivery, the questions, the memory and the trace. it arrives: Your backend asks for it with the SDK, signed with its key; so can a schedule, a webhook or you from the CLI. The same key gives the same task: a retry on your side never duplicates it. its turn: Every customer has their own queue and they are served in turns: one with a thousand tasks never holds back the rest. Your agent takes up to 4 at once; change it with concurrency. delivery: spredr brings it to your agent signed, with that customer's memory and the lessons in force. If it does not answer, it retries after 5 s, 30 s and 2 min. asks first: A risky action stops and waits for a person. When it comes back the task carries its diary: every answer and every step already done returns the same, so nothing happens twice. the result: Your agent answers right away or reports later. Whoever asked gets it by waiting, through their signed callback, or live, piece by piece. the trace: Every step stays with its time, its tokens and its cost. What you correct becomes a lesson, tested on past tasks before it goes in. between tasks: Your agent rests: about 36 MB and no CPU, and it answers the next task in milliseconds. If you choose to let it sleep, it stops after the quiet minutes you set and the first task wakes it; that task says how long it took to start. what it does well ## Nothing happens twice When a task comes back, after a question or a crash, every answer and every step it already took gives back what it gave the first time. The model is not paid twice and a customer is not charged twice. Your backend gives it tasks and waits for the result; you answer what it asks from the panel or from your app. asks first: A risky action waits for a person. Approved often enough, it is offered to run alone, and an undo takes that back. remembers: Memory by customer, and it forgets whoever asks. learns: Your corrections become lessons, tried on past tasks before they go live. any model: Claude, OpenAI, Gemini or your own, with your key: spredr never sits between your agent and its model. light: About 36 MB working and no CPU asleep; spredr adds about 10 ms per task. in view: Each task is a trace with its steps, tokens and cost, in your OpenTelemetry tools too. Costs ## What each task cost, and which ones stand out Every model call your agent makes shows its cost beside the task that made it. ctx.model() reads the model and its tokens, including the ones served from the prompt cache and the ones written to it, so each part is priced at its own rate. When your code sends no cost, spredr prices the tokens at the model's list price and marks the figure as an estimate, the way agent observability tools price a trace. A cost your code sends always wins. A model spredr has no price for shows no price rather than $0. The daily spend limit counts estimates too. A task is marked slow when it took longer than 95 % of its agent's tasks in the last day, and costly when it cost more than 95 % of them: the 95th percentile, the usual line for an outlier. Each agent is compared with itself, and only once it has 20 finished tasks that day. Input: Tokens billed in full, at the model's input rate. Cache writes: At 1.25 times the input rate. Cache reads: At the model's cache rate, or a tenth of its input rate. Output: Tokens the model wrote, at its output rate. --- # Your agent from your backend Your backend talks to your agent with the SDK, signing with its own key. spredr delivers what you send and what the agent answers; what you send and how it reads it is your code's business. ```sh npm install @spredr/sdk ``` once ## Link your backend With your spredr token, from a script or as you deploy. spredr writes the backend's key into its variables (SPREDR_CALLER_ID, SPREDR_CALLER_KEY, SPREDR_AGENT, SPREDR_AI_URL, SPREDR_AI_KEY) and deploys it: the private key never passes through you. ```ts import { Spredr } from "@spredr/sdk"; const spredr = new Spredr({ token: process.env.SPREDR_TOKEN }); await spredr.agent("shop").addCaller("shop-api", { service: "shop-api" }); ``` You can also do it in the panel, in your agent's Connections tab. To change the key, remove the link and make it again: the old one stops working at once. every message ## Ask it for a task Caller reads the variables spredr left. for() is the customer it works for (a shop, an account), with its own memory and limits. With key, asking again is the same task; with thread, its tasks read as one conversation. ```ts import { Caller } from "@spredr/sdk"; const agent = new Caller(); const shop = agent.for(shopId); const { reply } = await shop.result( "reply", { text }, { thread: `chat:${customerId}`, key: messageId }, ); ``` what it needs ## Give it context You decide what you give it and in what form; spredr makes sure it arrives. How the agent reads it is its code's business. in the task: What goes in input, up to 256 KB: the message, the customer, what changes every time. an address: A URL of your API the agent opens with its own code when it needs it. spredr never opens it. a session's file: A txt, json, csv or pdf of up to 10 MB you leave once per conversation: every task of that thread lists it. Your backend: ```ts await shop.attach(`chat:${customerId}`, "prices.csv", csv, { type: "text/csv", }); ``` Your agent: ```ts agent.on("reply", async (input, ctx) => { const prices = await ctx.file("prices.csv"); const text = new TextDecoder().decode(prices.data); return { reply: await answer(input.text, text) }; }); ``` live ## The answer as it is written If your agent uses ctx.stream, live() gives you each piece in order and then the finished task. If the connection drops, it goes on where it left off. ```ts for await (const event of shop.live("reply", { text })) { if (event.type === "delta") send(event.text); if (event.type === "end") done(event.task); } ``` the rest ## What else you can do questions: If your agent asks before it acts, pauses() gives you its questions and answer() answers them. notices: With a callbackUrl when you link, spredr tells your backend when each task ends, signed: believe it only when caller.callback() returns it. costs: The model runs on your key and you pay for it. Your plan counts the month's tasks, the agent's memory and its sessions' files. errors: Every error says why. When trying again is safe, the SDK does it for you. --- # Plans and limits You pay one plan for all your services, not a bill for each. Everything in the plan is shared by the services in your account. | | Starter, $5 / mo | Pro, $20 / mo | | --- | --- | --- | | services | 6 | 10 + $1 each | | memory | 1 GB | 4 GB + $2/GB | | sustained CPU | 0.5 vCPU | 2 vCPU | | one service's peak | 1 vCPU | 2 vCPU | | traffic | 100 GB | 500 GB | | own domains | 2 | 10 | | build minutes | 300 | 1,000 | | agents | up to 6 | 10 + $1 each | | agent tasks | 100 thousand | 1 million | | space for each agent | 100 MB | 1 GB | | tasks kept | 7 days | 60 days | | export your tasks | always | always | | traces over OpenTelemetry | included | included | memory: The sum of the limits you give each service, not what it uses at the moment. A single service can use all of the plan's. CPU: Measured on each service, minute by minute. Peaks spend credits that refill at your sustained CPU. going past it: With a paid plan, pay as you go comes on with a $10 monthly cap: what passes the plan is charged up to that cap and nothing slows down. If you turn it off, you never pay more: CPU slows down, builds and your agents' new tasks wait for next month and, at twice the traffic, the service pauses until month end. Agents' tasks are not sold by use. --- # Command line Publish, watch and configure your services from the terminal. Tokens and billing live in the panel. With --json, a script or an agent uses it just like you. install ## One file, checked The installer picks the build for your system and processor, checks its sha256 against the published list before installing anything and puts spredr in ~/.spredr/bin, for you only. ```sh $ curl -fsSL https://spredr.cloud/install | sh ``` ```sh $ irm https://spredr.cloud/install.ps1 | iex ``` SPREDR_VERSION: A given version instead of the latest. SPREDR_INSTALL: Another folder (spredr goes in its bin/). global flags ## They work on any command --json: Stable JSON for scripts and agents (one object per line while following). -s, --service : The service; not needed in a linked folder. --api : Talk to another control (local, staging). -y, --yes: Skip confirmations (never the browser approvals). -q, --quiet: Only errors. --no-color: Plain text, also with NO_COLOR. --ascii: No Unicode (automatic with TERM=dumb). every command ## Grouped like spredr help Ship [link Ties this folder to a service, so commands here need no name.](https://spredr.cloud/docs/cli/link)[unlink Unties this folder from its service.](https://spredr.cloud/docs/cli/unlink)[new Creates a service from a GitHub repo.](https://spredr.cloud/docs/cli/new)[rm Deletes a service.](https://spredr.cloud/docs/cli/rm)[deploy Deploys the newest commit of the service's branch and follows it until it is live (or fails), with the build as it happens.](https://spredr.cloud/docs/cli/deploy)[rebuild Builds the same commit again from scratch and deploys it.](https://spredr.cloud/docs/cli/rebuild)[releases A service's releases, newest first.](https://spredr.cloud/docs/cli/releases)[rollback Goes back to an earlier release: its image, no rebuild.](https://spredr.cloud/docs/cli/rollback)[start Turns a service back on with its last healthy release.](https://spredr.cloud/docs/cli/start)[stop Turns a service off.](https://spredr.cloud/docs/cli/stop) Watch [services Every service, its state and address.](https://spredr.cloud/docs/cli/services)[status How a service is doing: state, memory, CPU and traffic charts.](https://spredr.cloud/docs/cli/status)[top Every service live: memory, requests and restarts, every 2 s.](https://spredr.cloud/docs/cli/top)[open Opens a service's address, or its page in the panel.](https://spredr.cloud/docs/cli/open)[usage The last 24 hours, hour by hour: memory, CPU and traffic.](https://spredr.cloud/docs/cli/usage)[live One service live on one screen: memory, requests, latency, errors and its logs.](https://spredr.cloud/docs/cli/live)[logs What a service prints (-f to follow).](https://spredr.cloud/docs/cli/logs)[build A release's build log (the latest, or -r vN).](https://spredr.cloud/docs/cli/build)[activity What happened on your account: deploys, changes, sign-ins, refusals.](https://spredr.cloud/docs/cli/activity)[risks What puts your services at risk now, worst first, with the fix.](https://spredr.cloud/docs/cli/risks) Configure [settings How a service is built and runs: branch, folder, Dockerfile, start command, port, health path, memory, region.](https://spredr.cloud/docs/cli/settings)[vars Variables: list names, set, unset, or import a .env.](https://spredr.cloud/docs/cli/vars)[volume Persistent volume: see it, give it, restore a backup, or remove it.](https://spredr.cloud/docs/cli/volume)[domains Domains: list, add, verify, choose which one answers, remove.](https://spredr.cloud/docs/cli/domains) Account [login Connects this terminal to your account.](https://spredr.cloud/docs/cli/login)[logout Signs this terminal out: its token is revoked on the server.](https://spredr.cloud/docs/cli/logout)[whoami Who this terminal is signed in as, and what it may do.](https://spredr.cloud/docs/cli/whoami) This CLI [version The version, the system, and which control it talks to.](https://spredr.cloud/docs/cli/version)[doctor Checks everything that can go wrong on this machine, and how to fix it.](https://spredr.cloud/docs/cli/doctor)[config Shows or changes settings: api, color, updateCheck.](https://spredr.cloud/docs/cli/config)[completion Tab completion for bash, zsh, fish or PowerShell.](https://spredr.cloud/docs/cli/completion)[upgrade Updates spredr to the latest version (checked against its sha256).](https://spredr.cloud/docs/cli/upgrade) --- # For agents An agent or a CI can drive spredr just like you: every command answers in JSON, every error says how to fix it and the exit codes do not change. This page is what an agent needs to know. the whole documentation ## In a single text file All of this documentation, in Markdown and in English, is at /llms-full.txt. The short index, with one link per page, is at /llms.txt. ```sh $ curl -fsSL https://spredr.cloud/llms-full.txt ``` mcp ## spredr as your agent's own tools spredr mcp turns the CLI into an MCP server, so Claude Code, Cursor or any client that speaks MCP can deploy, roll back, read logs and status, and set variables and domains on its own. It signs in the way this terminal does (spredr login, or SPREDR_TOKEN), and every tool answers with the same JSON a script gets. ```sh $ claude mcp add spredr -- spredr mcp ``` In Claude Desktop, Cursor and other desktop apps: add it to their MCP settings with spredr's full path, because those apps do not read your terminal's PATH. Put your user name in place of you; which spredr (or where spredr on Windows) gives the exact path. ```sh mac {"mcpServers":{"spredr":{"command":"/Users/you/.spredr/bin/spredr","args":["mcp"]}}} linux {"mcpServers":{"spredr":{"command":"/home/you/.spredr/bin/spredr","args":["mcp"]}}} win {"mcpServers":{"spredr":{"command":"C:/Users/you/AppData/Local/spredr/bin/spredr.exe","args":["mcp"]}}} ``` ship: deploy, rebuild, rollback, start, stop, create_service watch: list_services, service_status, logs, build_log, releases, usage, risks, activity configure: settings, vars_list, vars_set, vars_unset, domains_list, domain agents: agents_list, agent_info, ask_agent, answer_question The token decides what the tools can do: with a read token, deploy answers that it needs more access. Signing in, signing out and deleting a service are not tools: they stay with a person. no browser ## A token instead of spredr login spredr login needs a person to approve it in the browser. For an agent, create a token in your account, under Tokens: you choose what it may do and until when (or no end), and it is shown once. Pass it in SPREDR_TOKEN. ```sh $ export SPREDR_TOKEN= $ spredr whoami --json ``` read: Look only: services, state, logs, usage and activity. deploy: What read does, plus deploying. It doesn't change variables, domains or services. full: Everything, variables, domains and services too. No token can create or see other tokens. Give each agent the smallest scope that works for it, and a token of its own: you can revoke it without touching the others. json ## Everything in JSON With --json, every command prints one stable JSON object. While it follows something (a deploy, logs -f) it prints one per line. An error is JSON too, with three fields. ```sh $ spredr deploy mi-api --json $ spredr risks --json ``` error: What happened, in one sentence. hint: How to fix it: the next step worth taking. exit: The same code the command exits with. exit codes ## To decide without reading the text 0: It worked. 1: It failed: the deploy didn't go live, the network didn't answer, something broke. 2: The command is wrong: a missing argument or a flag that does not exist. 3: No permission: no token, it expired, its scope isn't enough or the approval was denied. 5: It doesn't exist: the service, release or domain you named. no prompts ## So it never waits on a prompt -y, --yes: Skips confirmations. Never skips a browser approval. rm --confirm: spredr rm asks you to type the name; --confirm gives it up front. SPREDR_SERVICE: The service for every command, without typing it. SPREDR_API: Another control (local, staging). SPREDR_SECRETS=file: Keeps the session in a file: for CI and containers with no keyring. SPREDR_NO_BROWSER=1: Never opens the browser. SPREDR_NO_UPDATE_CHECK=1: Doesn't check for new versions (with CI it doesn't either). asking the CLI ## The help for your version spredr help gives the exact flags and examples of the installed version, and spredr doctor checks what can go wrong on that machine. ```sh $ spredr help deploy $ spredr doctor --json ``` --- # `spredr link` Ties this folder to a service, so commands here need no name. ### Usage ```sh $ spredr link ``` ### Examples ```sh $ spredr link mi-api ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr unlink` Unties this folder from its service. ### Usage ```sh $ spredr unlink ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr new` Creates a service from a GitHub repo. ### Usage ```sh $ spredr new [--name ] [--branch main] [--port 8080] [--memory 256] [--health /health] [--region us|eu] [--deploy] ``` ### Flags --name : The service name (default: the repo's name). --branch : The branch to follow (default: main). --port : The port your app listens on. --memory : Its memory limit. --health : A path that answers 200 when it is ready. --region : Where it runs: the region closest to its database (default: us). --deploy: Deploys it right away and follows it. ### Examples ```sh $ spredr new tu-usuario/mi-api --port 4310 --health /health ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr rm` Deletes a service. It asks you to type its name. ### Usage ```sh $ spredr rm [--confirm ] ``` ### Flags --confirm : The name again, for a script. [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr deploy` Deploys the newest commit of the service's branch and follows it until it is live (or fails), with the build as it happens. What was live keeps serving until the new release answers its health path. ### Usage ```sh $ spredr deploy [servicio] [--detach] ``` ### Flags --detach: Returns as soon as it is queued. --verbose: The whole build log as it happens, not just its steps. ### Examples ```sh $ spredr deploy $ spredr deploy mi-api --json ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr rebuild` Builds the same commit again from scratch and deploys it. ### Usage ```sh $ spredr rebuild [servicio] [--detach] ``` ### Flags --detach: Returns as soon as it is queued. --verbose: The whole build log as it happens. ### Examples ```sh $ spredr rebuild ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr releases` A service's releases, newest first. ### Usage ```sh $ spredr releases [servicio] [-n 20] ``` ### Flags -n : How many to show. [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr rollback` Goes back to an earlier release: its image, no rebuild. ### Usage ```sh $ spredr rollback [servicio] ``` ### Examples ```sh $ spredr rollback v3 $ spredr rollback mi-api v3 ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr start` Turns a service back on with its last healthy release. ### Usage ```sh $ spredr start [servicio] ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr stop` Turns a service off. Its releases, variables and domains stay. ### Usage ```sh $ spredr stop [servicio] ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr services` Every service, its state and address. ### Usage ```sh $ spredr services ``` Also: spredr ls [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr status` How a service is doing: state, memory, CPU and traffic charts. ### Usage ```sh $ spredr status [servicio] ``` ### Examples ```sh $ spredr status $ spredr status mi-api --json ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr top` Every service live: memory, requests and restarts, every 2 s. ### Usage ```sh $ spredr top ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr open` Opens a service's address, or its page in the panel. ### Usage ```sh $ spredr open [servicio] [--panel] ``` ### Flags --panel: Its page in the spredr panel instead. [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr usage` The last 24 hours, hour by hour: memory, CPU and traffic. ### Usage ```sh $ spredr usage [servicio] ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr live` One service live on one screen: memory, requests, latency, errors and its logs. Refreshes every 2 s until q. Keys: p only problems, / filter, space pause, r and l pick a column on a narrow screen, d deploys the latest commit (asks first), q quits. ### Usage ```sh $ spredr live [servicio] ``` ### Examples ```sh $ spredr live $ spredr live mi-api ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr logs` What a service prints (-f to follow). ### Usage ```sh $ spredr logs [servicio] [-f] [--stream runtime|deploy|network] [--grep texto] [--problems] [--verbose] [-n 100] ``` ### Flags -f, --follow: Keeps printing new lines. --stream : runtime (default), deploy or network (the requests it served). --grep : Only lines with this text. --problems: Only errors and warnings. --verbose: Each line with all it knows: a JSON line's every field; a request's host, client, timings and sizes. -n, --limit : How many lines to start with. ### Examples ```sh $ spredr logs -f $ spredr logs mi-api --problems $ spredr logs --stream network --grep 500 --verbose ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr build` A release's build log (the latest, or -r vN). ### Usage ```sh $ spredr build [servicio] [-r vN] ``` ### Flags -r : The release. [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr activity` What happened on your account: deploys, changes, sign-ins, refusals. ### Usage ```sh $ spredr activity [-n 30] [--grep texto] ``` ### Flags -n : How many lines. --grep : Only those with this text. [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr risks` What puts your services at risk now, worst first, with the fix. ### Usage ```sh $ spredr risks [servicio] ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr settings` How a service is built and runs: branch, folder, Dockerfile, start command, port, health path, memory, region. ### Usage ```sh $ spredr settings [servicio] [--branch b] [--root carpeta] [--dockerfile ruta] [--command cmd] [--port n] [--health /ruta] [--memory MB] [--region us|eu] ``` ### Examples ```sh $ spredr settings $ spredr settings mi-api --memory 512 $ spredr settings mi-agente --root apps/agent --command 'node src/agent.ts' $ spredr settings mi-api --region eu ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr vars` Variables: list names, set, unset, or import a .env. Values are encrypted and never shown in a terminal; to read one back, use the panel (each read is logged). Changes apply from the next deploy. ### Usage ```sh $ spredr vars [servicio] · vars set KEY=valor … · vars unset KEY … · vars import ``` ### Examples ```sh $ spredr vars $ spredr vars set DATABASE_URL=postgres://… LOG_LEVEL=info $ spredr vars unset OLD_KEY $ spredr vars import .env.production $ cat .env | spredr vars import - ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr volume` Persistent volume: see it, give it or resize it, go back to a backup, or remove it. The same rules as the panel and spredr.json; its key never comes out. ### Usage ```sh $ spredr volume [servicio] · volume set [servicio] [--size GB] [--path /data] · volume restore [servicio] [--from latest] --yes · volume rm [servicio] --confirm ``` --size : How much it may hold, in GB. --path : Where your app sees it. /data if you leave it out. --from : The backup to put back: latest, or its id. --confirm : The service's name, to remove the volume without an interactive terminal. ### Examples ```sh $ spredr volume $ spredr volume set --size 5 $ spredr volume set mi-api --path /var/data $ spredr volume restore mi-api --yes $ spredr volume rm mi-api --confirm mi-api ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr domains` Domains: list, add, verify, choose which one answers, remove. A domain answers only after you prove it is yours with a DNS TXT record. Only one address answers at a time: a verified domain of yours, or the service's own name. ### Usage ```sh $ spredr domains [servicio] · domains add|verify|use|rm ``` ### Examples ```sh $ spredr domains $ spredr domains add api.tudominio.com $ spredr domains verify api.tudominio.com $ spredr domains use api.tudominio.com $ spredr domains use own ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr login` Connects this terminal to your account. Opens a page where you check the code, choose what this terminal may do and for how long, and approve it. You never paste a token; it's kept in your system's secret store. Ctrl+C cancels and closes the page. ### Usage ```sh $ spredr login [--api ] [--no-browser] ``` ### Flags --api : Signs in to another control (local, staging) and makes it the current one. --no-browser: Prints the link instead of opening it. --force: Signs in again even if this terminal already is. ### Examples ```sh $ spredr login $ spredr login --no-browser ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr logout` Signs this terminal out: its token is revoked on the server. ### Usage ```sh $ spredr logout ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr whoami` Who this terminal is signed in as, and what it may do. ### Usage ```sh $ spredr whoami ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr version` The version, the system, and which control it talks to. ### Usage ```sh $ spredr version ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr doctor` Checks everything that can go wrong on this machine, and how to fix it. ### Usage ```sh $ spredr doctor ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr config` Shows or changes settings: api, color, updateCheck. ### Usage ```sh $ spredr config [get · set · reset] ``` ### Examples ```sh $ spredr config $ spredr config set color never $ spredr config reset ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr completion` Tab completion for bash, zsh, fish or PowerShell. ### Usage ```sh $ spredr completion ``` ### Examples ```sh $ spredr completion zsh >> ~/.zshrc $ spredr completion fish > ~/.config/fish/completions/spredr.fish ``` [back to the command line](https://spredr.cloud/docs/cli) --- # `spredr upgrade` Updates spredr to the latest version (checked against its sha256). ### Usage ```sh $ spredr upgrade [--force] ``` ### Flags --force: Installs the latest build even if this one is the same version. [back to the command line](https://spredr.cloud/docs/cli)