Render
Hosting dashboards and scheduled jobs
A hosting platform. You point it at a repository and it builds and runs the service, with an API for deploys, environment variables and scheduled jobs.
Render is where the small internal things live: a dashboard a team looks at every morning, a job that runs twice a day and refreshes a map of tables, a webhook receiver. None of it is big enough to deserve infrastructure work, which is exactly the case Render is good at.
How I use it
Deploys are triggered on purpose. I do not wait for the automatic build to fire off a push. I call the deploy endpoint myself with the cache cleared, then poll it until it reports a final state. That way I know which deploy belongs to which change, and I stop losing time to a build that served an old file from cache while the code was already right.
Config that a person edits lives in an environment variable. The disk does not survive a redeploy, so a settings file written by the running app is gone at the next build. The single variable endpoint updates one value without replacing the rest and without restarting anything, so the app keeps the live value in memory and writes it through to survive the next deploy.
Identify the service before touching anything. Names overlap, especially once there is a staging copy of something. I probe the live URL and confirm against the API which service is actually serving it, before I edit a single file.
Scheduled jobs are just the same repo on a timer. A cron service running the same code as everything else means one place to read, one place to fix, and no separate machine that only one person knows about.
What I have learned the hard way
A restart does not pick up a new environment variable. It returns success, it creates no new deploy, and the process comes back reading the old value from the previous deploy’s snapshot. Only a deploy re-reads them. I chased a change that had already been made for far too long because the restart reported fine.
The bulk environment variable endpoint replaces everything. Send it two keys and the service has two keys, and every other credential it needs is gone. I took a production service down that way once. Now anything touching that endpoint fetches the current set, merges, and sends the whole list back.
Green build, broken site is a real state. The build runs the build command. It does not check that the container copied the files the app serves, so a missing static folder ships as a page with no styling and no working buttons, past every test that passed locally. After any deploy that moves files, I check the health endpoint and a static asset both return successfully before calling it done.
Deploying the same commit is the safe way to apply a config change. Read which commit is live, confirm it matches the branch, then deploy that exact commit. The environment changes and the code does not.
Resources
This is one part of a stack. The rest is on the tools page, and what I build with it is on work.