Render access & service ownership

How Render workspaces, members, and services work — inviting people, managing environment groups, and transferring ownership.

Render hosts long-running back-end services: APIs, background workers, cron jobs, managed databases, and static sites. Where a front-end platform deploys pages, Render runs processes that stay up.

Quick summary

Access is organised by workspace; the people in one are its team members. Invite them from the workspace's Settings page and give the lowest role that works. Environment variables live per service, with environment groups for values shared across several services. Two things to get right early: Render cannot move an existing service to a different workspace, so create it in the workspace that should own it; and a deleted service can be rebuilt from your code, while a deleted database's data may be gone for good.

How Render organises things

Workspace — the billing and permission boundary that owns everything else.

Service — one running thing: a web service, a background worker, a cron job, or a static site. Each has its own environment variables, logs, and deploy history.

Datastore — Render Postgres, or Render Key Value (Render's Redis-compatible store), each with its own credentials. Paid Postgres databases get point-in-time recovery; free ones get no recovery at all. See managed PostgreSQL.

Environment group — a named set of variables attached to multiple services, so a shared value is changed once rather than in six places.

Roles

Every plan has two roles. Admin has full access, including member management, billing and workspace settings. Developer can work on the workspace's services and environment groups but not its organisational settings.

Render's Scale plan and above add three more: Contributor, which can deploy and roll back but can't create, change or delete most resources, can't see connection strings, environment variables or billing details, and can't open a shell on a running service; Viewer, which is read-only and also can't see logs or those sensitive fields; and Billing, which covers billing only.

Grant Admin sparingly. Developer is enough for almost all engineering work — but it can read environment variables and connection strings, so it isn't a low-trust role. If you want genuinely restricted access, Contributor and Viewer are the ones that withhold secrets, and they need a Scale plan.

Inviting someone

Check you're in the right workspace. The workspace dropdown sits at the top of the left pane — inviting into the wrong workspace is a common slip. Note that team members can't be added to a Hobby workspace at all; that needs a Pro plan or higher.

Open the workspace's Settings from the left pane and scroll down to Team members.

Click + Invite members, enter the email address, and pick the role.

Require two-factor authentication. Anyone who can deploy can reach production data.

Environment variables and secret files

Each service holds its own variables on its Environment page. Render also supports secret files — whole files (certificates, service-account JSON) made available to the service at runtime rather than pasted into a single variable. They appear under /etc/secrets/ at runtime, and all of a service's secret files together can't exceed 1 MB.

Changing a variable triggers a redeploy

Saving environment changes redeploys the service by default. Render gives you three save options — Save, rebuild, and deploy, Save and deploy, and Save only — and only the last one defers the change to your next deploy. On a production API a redeploy means a brief interruption, so batch your changes and apply them in a planned window rather than one at a time.

Databases deserve extra care

A deleted database may not be recoverable

Suspending or deleting a managed datastore can destroy the data permanently, and Render's free tier expires on a clock: a free Postgres database expires 30 days after creation, and after a 14-day grace period Render deletes it along with all of its data. Free databases also get no point-in-time recovery. Before any destructive action: take a manual backup, download it somewhere outside Render, and confirm you can read it. See backups explained.

Also worth knowing:

Internal connection strings work only between services in the same workspace and region; external ones are reachable from anywhere and should be restricted by IP where possible.
Rotating Postgres credentials on Render means adding a new database user, pointing every service at it, and then deleting the old one. An environment group makes the middle step one change instead of six.

Transferring ownership

Render does not move existing services between workspaces. Its own FAQ says this is not currently possible, and offers two alternatives: invite people into the workspace that already holds the services, or recreate the services in the workspace you want them in.

That makes ownership something you settle at the start rather than hand over at the end.

Create everything in the workspace that should own it — yours, on your billing. This is the decision that is expensive to undo later.

Add us as team members of your workspace rather than building in ours. Removing us afterwards doesn't touch a single service.

If a move really is unavoidable, plan a rebuild, not a transfer: back up every datastore and store the dump outside Render, recreate the services in the destination workspace, and re-enter environment variables and environment groups.

Re-check custom domains and TLS certificates, which will need setting up again on the new services.

Rotate credentials so the previous owner's copies stop working.

Common questions

Why did my service go to sleep?

Render spins down a free web service once it goes 15 minutes without any inbound traffic. The next request wakes it up, and that takes about a minute — Render shows a loading page to browsers while it happens. For anything user-facing or handling webhooks, use a paid instance type: a webhook that times out is usually treated as failed by the sender.

How do we see what went wrong in production?

Render's log explorer handles text search, filters, wildcards and regular expressions per service. The limits are retention and volume: logs are kept for 7 days on a Hobby workspace, 14 on Pro and 30 on Scale or Enterprise, older lines are gone even if you upgrade afterwards, and Render drops anything above 6,000 application log lines per minute per instance. Pair logs with error tracking — see Sentry.

Who should own the Render workspace?

You. It holds your API, your database, and your billing. We work inside your workspace as members, and our access can be removed at any time without touching the services themselves.

What happens to background jobs during a deploy?

A deploy replaces running instances. Jobs mid-flight can be interrupted unless the application handles shutdown signals and the work is idempotent or queued. Worth confirming before scheduling deploys during business hours.

Need a hand?

If you're stuck, email support@chykalophia.com and we'll help. Include your website address and a screenshot if you can.