Render

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 3 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. No prompts to fill. The Blueprint declares no sync: false env vars — Secrets__JwtKey and Secrets__EncryptionKey auto-mint at first deploy via generateValue: true, and Database__TransactConnection / Database__MartConnection are wired from the Postgres resource via fromDatabase. Click Apply Blueprint and Render goes straight to provisioning.
2. 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 (✓):
   
3. Open https://<your-api>.onrender.com/startup to land in the first-run wizard.
4. Configure storage and email post-install. Once you’re logged in as admin:
   • Settings → System → Storage — pick S3-compatible, paste your bucket details. See Configure storage and email for provider-specific recipes (R2 is the recommended default — zero egress, S3-compatible).
   • Settings → Mail → Outbound — pick Resend (paste API key) or SMTP (host + credentials + from-address). Required before any email-dependent flow (password reset, two-factor login, new-user invitations) will succeed.
   Both sets of credentials are encrypted at rest in the database using Secrets__EncryptionKey, so they never appear in the Render dashboard environment panel.

The JWT signing key and encryption key are both auto-generated by Render at first deploy and preserved across redeploys. You don’t need to set or rotate them 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

Configure the bucket post-install via Settings → System → Storage in the running app. Provider-specific recipes (Cloudflare R2 — recommended default, AWS S3, Backblaze B2, MinIO) and the wrong-page warning for R2 token creation are in Configure storage and email.

​

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

• Configure storage and email — admin-UI walkthrough for the S3 bucket + Resend/SMTP setup that lands post-install
• Configuration reference — ekso.json (Secrets + Database) and the env-var override mechanisms Render uses
• 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