Render

Documentation Index

Fetch the complete documentation index at: https://ekso.dev/llms.txt

Use this file to discover all available pages before exploring further.

Render is the cloud-platform install path: managed Postgres, web service for the API, background worker, and your own S3-compatible bucket for uploaded attachments. One Blueprint provisions everything; redeploys pull the latest images automatically.

​

Why this differs from the Docker bundles

The Docker bundles mount a shared host folder for uploaded attachments — the app and worker containers both read and write the same directory. Render’s persistent disks are bound to a single service, so that pattern doesn’t work there. This install path uses Ekso’s S3 storage backend instead: attachments live in your bucket, the app and worker services read and write it independently, and durability is delegated to your bucket provider’s versioning and lifecycle rules. The trade-off is one extra moving part (the bucket) for the cloud-platform shape that Render’s pricing model is built around.

​

Prerequisites

• A Render account with billing set up. The smallest viable shape is one Starter web service + one Starter worker + Basic-1gb Postgres — roughly $37–43/month at current pricing (table below).
• A GitHub account to push render.yaml to a repo Render can read.
• An S3-compatible bucket with an access key. Cloudflare R2 is the recommended default — zero egress fees, S3-compatible, and what render.yaml defaults to. AWS S3, Backblaze B2, and MinIO all work too. See bucket setup below.
• A free Ekso license. Fetch one at ekso.app/get-started. Free tier is unlimited users, no credit card.

​

Install

Two ways to start. Both produce the same Render Blueprint and end at the same place — pick whichever fits your situation.

​

Automatic

1. Click the button above. Render takes you to its Blueprint preview screen, with the source set to EksoApp/Deploy-to-Render (the public canonical mirror of render.yaml).
2. Sign in to Render if you aren’t already, then approve.
3. Continue with the shared steps below.

​

Manual

1. Download ekso-render.zip. It contains:

   File	Purpose
   render.yaml	The Blueprint: Postgres + web + worker + env-var config
   README.md	Bundle-local quick reference (frozen at download time)

2. Push render.yaml to a GitHub repo you own:
   curl -L https://ekso.app/download/ekso-render.zip -o ekso-render.zip
   unzip ekso-render.zip -d ekso-render && cd ekso-render
   git init && git add render.yaml README.md
   git commit -m "Ekso on Render"
   git remote add origin [email protected]:YOU/ekso-render.git
   git push -u origin main
   
3. In Render: New + → Blueprint → connect the repo from step 2.
4. Continue with the shared steps below.

​

After Render connects

Both paths converge here.

1. Set up your S3-compatible bucket and capture the credentials. See bucket setup — the R2 walkthrough is the fastest path.
2. Fill in the bucket fields when Render prompts. The Blueprint declares them sync: false, so they’re requested at deploy time (not committed to any repo). The preview page shows them grouped under each service — fill identical values in both ekso-api and ekso-worker blocks:
   

   Field	Value
   Storage__S3Bucket	Your bucket name (e.g. ekso-attachments)
   Storage__S3Endpoint	Provider’s S3 endpoint URL (see bucket setup)
   Storage__S3AccessKey	Access Key ID
   Storage__S3SecretKey	Secret Access Key

   Storage__S3Region defaults to auto (correct for Cloudflare R2). Override to your AWS / B2 region if you’re using those.
3. Wait ~2 minutes. Render provisions the database first (web + worker depend on it), then builds and starts both services in parallel. The Blueprint progress page shows resources moving from queued (⏳) to deployed (✓):
   
4. Open https://<your-api>.onrender.com/startup to land in the first-run wizard.

The JWT signing key was auto-generated by Render at first deploy (generateValue: true in the Blueprint). You don’t need to set or rotate it manually — treat the Render dashboard environment panel like a password file once the deploy is live.

​

What’s running

Three Render resources come up: Plus your bucket (external to Render) for uploaded attachments. The bucket lives in your cloud provider’s account, not Render’s — destroying the Render workspace doesn’t touch it, and the access key in Render’s dashboard is the only thing that lets the API talk to it. For the full data layout, backup story, and restore procedures across both Local and S3 storage backends, see Data management.

​

Bucket setup

The Storage section of ekso.json (env-var-injected on Render) accepts any S3-compatible store. Provider-specific setup:

• Cloudflare R2 — recommended default. Zero egress, generous free tier, S3-compatible. Pay attention to the wrong-page warning: R2 credentials must come from the R2 dashboard’s own token page, not Cloudflare’s account-wide “Account API tokens”.
• AWS S3 — most familiar to AWS shops. Set Storage__S3Region to your bucket’s region; leave Storage__S3Endpoint blank.
• Backblaze B2 — cheapest cold storage. Endpoint format is https://s3.<region>.backblazeb2.com.
• MinIO — only if you’re running self-hosted MinIO somewhere reachable from Render’s network (rare, but supported).

​

Recommended bucket settings (any provider)

• Versioning enabled — recovers a deleted or overwritten object. Equivalent to the Docker bundles’ 14-day storage snapshots, but at object granularity.
• Lifecycle rule auto-expiring non-current versions after 30 or 90 days so versioned data doesn’t accumulate forever.

See Data management → Attachment durability for restore patterns.

​

Cost shape

Approximate, at the time of writing — check Render pricing for canonical numbers: AWS S3 adds an egress component (data leaving the bucket); B2 sits between R2 and AWS. Render’s bandwidth from the web service is included in the Starter plan up to 100 GB/month.

​

Backups

Render Postgres takes daily automatic backups with point-in-time recovery on every paid plan — there’s nothing to wire up. Restore from the Render dashboard: Database → Recovery → pick a timestamp. Attachment durability is your bucket provider’s job. Configure versioning plus a lifecycle rule (above), and you’re covered for the same kinds of mistakes the Docker bundle’s backup sidecar covers — accidental deletes, overwrites, ransomware. See Data management → S3 storage.

​

Pointing it at a real domain

Render assigns each service a <service>.onrender.com hostname with HTTPS terminated at the edge — fine for evaluation. For production, add a custom domain in the Render dashboard: Service → Settings → Custom Domain. Render auto-provisions a Let’s Encrypt certificate. Use that domain as the public URL during the first-run wizard.

​

Updating

Render redeploys when you push to your render.yaml repo, or you can trigger a manual redeploy from the dashboard to pull the latest eksoapp/app:latest and eksoapp/worker:latest images. To pin a specific version, change the image.url in render.yaml from docker.io/eksoapp/app:latest to docker.io/eksoapp/app:1.X and push. Same for eksoapp/worker. Release cadence and version pinning: Upgrading.

​

Tearing it down

In the Render dashboard, deleting the Blueprint deletes all three resources (web, worker, database). Your bucket is in your own cloud account — Render can’t touch it; delete it yourself if you don’t need the data.

​

See also

• Configuration reference → Storage — every field of the Storage section
• Data management → S3 storage — backup and restore patterns when attachments live in a bucket
• First-run wizard — what to expect at /startup on first boot
• Upgrading — release cadence, version pinning, rollback