Render

Deploy Ekso to Render — managed Postgres, web service, background worker, plus your own S3-compatible bucket for attachments. Cloud-platform install path.

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.

Running on your own machine instead? Use Docker - full stack for the bundled Postgres path or Docker - bring your own database if you already have a Postgres / SQL Server you want Ekso to share. The Render path is a separate target — same code, different operational shape.

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.

Path	When to pick it
Automatic	One-click via Render’s Deploy button. Fastest path; Render reads the Blueprint from Ekso’s public repo. Best for evaluation and quick spin-ups.
Manual	Download the Blueprint and push it to your own GitHub repo. You own the YAML — Ekso’s future updates don’t reach your install unless you re-download. Best for production deploys you’ll manage long-term.

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.

Heads-up: when you use the automatic path, your install tracks Ekso’s public Blueprint. If we update render.yaml (e.g. to bump a Postgres tier or pin a new image version), Render will sync the change on your next redeploy. That’s usually a feature (security patches, plan-name fixes — like the starter → basic-1gb rename Render did in late 2025), but if you’d rather pin, use the manual path instead.

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 [e-mail]: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:

Resource	Type	Role
ekso-api	Web Service (Docker image eksoapp/app:latest)	REST API + UI behind Render’s HTTPS edge
ekso-worker	Background Worker (Docker image eksoapp/worker:latest)	Background jobs — email, ticketing, vector indexing
ekso-db	Managed Postgres 18 with pgvector	OLTP + reporting database

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:

Resource	Plan	Approx / month
Postgres	Basic-1gb	$23.50
Web service (ekso-api)	Starter	$7
Background worker (ekso-worker)	Starter	$7
Cloudflare R2 storage	First 10 GB free	$0–5
Cloudflare R2 egress	Free, all tiers	$0
Total		~$37–43

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.

Deleting the database is permanent. Take a Render manual backup (Database → Recovery → Take backup) and download it before deletion if there’s any chance you’ll want the data back.

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