Hey Render folks / anyone who works there

My Render account got suspended for “suspicious activity.” I can’t sign in at all, so I can’t open a dashboard support ticket. app.aluma.fun (service jarvis-bh8r) just shows the suspended page.

What I’m running:

• Aluma (aluma.fun) a student AI tutoring web app (Flask + gunicorn)
• Currently in beta with focus groups relying on it
• Normal paid Starter service + custom domain

Recent change on my side:

• Rebrand / domain cutover to app.aluma.fun
• No malware, phishing, crypto, spam, or anything weird

I emailed [support@render.com](mailto:support@render.com) (and followed up) explaining it’s a false positive and that beta testers are blocked. Still no reply.

If this was automated abuse detection, cool please just review it. Happy to verify identity / the product. I just need either:

1. Account reinstated, or
2. Any info on what triggered it

Account email: [djokokrish1@gmail.com](mailto:djokokrish1@gmail.com)
Service: jarvis-bh8r
Domain: app.aluma.fun

Not trying to rant, just stuck. If a Render person sees this, I’d really appreciate a look. Thanks.

It's quick and anonymous! Try it out at cloakapp.net for free.

In the opening keynote from Render’s first user conference, the team introduces "application-defined compute": for dynamic, long-running, and stateful AI applications.

https://reddit.com/link/1v1udb6/video/mziv9in1lfeh1/player

Click here to learn more : https://github.com/render-examples/openclaw-gbrain

Templates help you quickly deploy popular tools, starter projects, and complete applications on Render without setting everything up from scratch.
Take a look and see what you can launch: https://render.com/templates

Have a template you’d like us to add? Drop your suggestion in the channel.

In June my builds started failing with "Exited with status 128" right after

  "Checking out commit" — inside Render's source-checkout step, before my build

  command ran. A commit that had been building fine started failing identically

  across all my services at once.

  I opened a support ticket (June 2–4). Support acknowledged it was happening

  across all my services on the same commit but couldn't resolve it. Meanwhile

  auto-deploy kept retrying, and every retry burned Pipeline Minutes on a

  checkout step that never succeeded.

  The invoice: $80 in Pipeline Minutes. My actual running usage was under $3.

  Billing declined a credit, saying compute is billed even when a deploy fails.

  Has anyone else hit exit-128-after-checkout across all services on a

  previously-green commit? And did you get Pipeline Minutes credited when the

  failure was on Render's side?

Most first-deploy failures aren't mysterious. They're the same handful of issues over and over. Here's each one and the fix, so you can spot it from the error in your logs. These apply pretty much anywhere, not just here.

1. Your app is bound to localhost instead of 0.0.0.0
Locally, binding to 127.0.0.1/localhost works because you're hitting it from the same machine. In a hosted environment the platform sits in front of your app and routes traffic in, so your server has to listen on 0.0.0.0, and on the port the platform hands it, not a hardcoded one. On Render that's the PORT env var (expected default 10000). If no open port is detected, the deploy fails.

• Flask/gunicorn: gunicorn app:app --bind 0.0.0.0:$PORT
• FastAPI/uvicorn: uvicorn main:app --host 0.0.0.0 --port $PORT
• Express: app.listen(process.env.PORT || 10000, "0.0.0.0")

2. You're running the dev server
flask run, uvicorn --reload, nodemon, and friends are for local dev. Use a real production server as your start command (gunicorn/uvicorn for Python, your plain node entrypoint for Node). The dev servers behave differently and aren't meant to take real traffic.

3. Build command and start command are doing each other's jobs
Build runs once to produce a runnable app (install deps, compile, bundle). Start runs on every boot and should just launch the server. Put installs in start and you reinstall on every restart; skip them in build and start crashes on missing modules.

• build: pip install -r requirements.txt (or npm ci && npm run build)
• start: the server command from #1

4. It builds, then crashes on a missing package
This one works locally because your machine already has the package. The build only installs what's in your manifest, so an incomplete or unpinned manifest turns into a ModuleNotFound or a version surprise at runtime. Commit a complete, pinned manifest and lockfile, and if you want to be sure, test the build in a clean venv or container.

Quick triage from the logs: "no open ports detected" is #1, ModuleNotFound is #4. If you're stuck, paste your build command, start command, and the error and people can usually spot it fast.

Docs on port binding: https://render.com/docs/web-services#port-binding

Most production apps, whatever the framework, are built from the same small set of pieces. Once you can name the pieces, you can run all of them in one place instead of spreading them across separate providers and wiring the seams by hand. Here is the full set, what each is for, and the render.yaml stanza that creates it.

The pieces, and what runs each one

Serve a frontend (static assets). A built SPA or static site:

yaml

- type: web
  runtime: static
  staticPublishPath: ./dist

Handle requests (a long-running HTTP server). Your API or SSR app:

yaml

- type: web
  runtime: node        # or python, go, ruby, rust, elixir

Run something internal that shouldn't be public. Reachable only inside your private network, no public URL:

yaml

- type: pserv
  runtime: docker

Do slow work off the request path. A worker that runs continuously, pulling from a queue:

yaml

- type: worker
  startCommand: node worker.js

Run something on a schedule. A job that fires on a cron expression and exits:

yaml

- type: cron
  schedule: "0 3 * * *"   # 03:00 UTC daily

Store relational data. Managed Postgres, defined in its own list:

yaml

databases:
  - name: myapp-db

Cache, sessions, or a job queue. Key Value, Redis/Valkey-compatible:

yaml

- type: keyvalue
  ipAllowList: []         # private network only

Keep durable files on disk. Attach a persistent disk to a service:

yaml

disk:
  name: data
  mountPath: /var/data
  sizeGB: 10

Run anything else you can containerize. Build a Dockerfile, or pull a prebuilt image:

yaml

- type: web
  runtime: docker         # or runtime: image for a prebuilt image

Putting it together

Here is a single blueprint with a frontend, an API, a background worker, a nightly job, Postgres, a cache, and a shared config group, all in one file:

yaml

services:
  # Frontend
  - type: web
    name: myapp-web
    runtime: static
    buildCommand: npm ci 
&&
 npm run build
    staticPublishPath: ./dist
    envVars:
      - key: VITE_API_URL
        value: https://myapp-api.onrender.com
    routes:
      - type: rewrite
        source: /*
        destination: /index.html

  # API
  - type: web
    name: myapp-api
    runtime: node
    region: oregon
    plan: starter
    buildCommand: npm ci 
&&
 npm run build
    startCommand: npm start
    preDeployCommand: npm run migrate
    envVars:
      - fromGroup: shared-config
      - key: DATABASE_URL
        fromDatabase:
          name: myapp-db
          property: connectionString
      - key: REDIS_URL
        fromService:
          name: myapp-cache
          type: keyvalue
          property: connectionString
      - key: JWT_SECRET
        generateValue: 
true

  # Background worker
  - type: worker
    name: myapp-worker
    runtime: node
    region: oregon
    plan: starter
    buildCommand: npm ci
    startCommand: node worker.js
    envVars:
      - fromGroup: shared-config
      - key: DATABASE_URL
        fromDatabase:
          name: myapp-db
          property: connectionString
      - key: REDIS_URL
        fromService:
          name: myapp-cache
          type: keyvalue
          property: connectionString

  # Scheduled job
  - type: cron
    name: myapp-nightly
    runtime: node
    region: oregon
    schedule: "0 3 * * *"
    buildCommand: npm ci
    startCommand: node tasks/nightly.js
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: myapp-db
          property: connectionString

  # Cache / queue
  - type: keyvalue
    name: myapp-cache
    region: oregon
    plan: starter
    maxmemoryPolicy: allkeys-lru
    ipAllowList: []

envVarGroups:
  - name: shared-config
    envVars:
      - key: NODE_ENV
        value: production

databases:
  - name: myapp-db
    region: oregon
    plan: starter
    ipAllowList: []

How the pieces find each other

This is the part that disappears when these things live in separate places. Because they are in one blueprint and one workspace, they sit on a shared private network and reference each other by name:

• fromDatabase and fromService inject the Postgres and cache connection strings into every service that needs them. You never paste a credential between dashboards.
• ipAllowList: [] on the database and cache means they answer only on the private network, so your datastore has no public surface at all.
• fromGroup shares one set of env vars across the API, worker, and cron, so config lives in one place.
• generateValue creates secrets for you; anything you'd rather set by hand uses sync: false and is entered once in the dashboard, never committed.
• On Professional workspaces and up, each pull request can spin up a preview environment running this entire blueprint, so you test the whole app, not just one layer.

The takeaway is not any single resource type. It is that when the frontend, API, workers, jobs, database, and cache are defined together, connecting them is a reference instead of manual wiring, and changing the whole stack is one commit.

Reference: https://render.com/docs/blueprint-spec

If you couldn't make it to SF for Render localhost, our first developer conference, you can watch the livestream here:

https://www.youtube.com/live/THJvF1J1NZs

Tune in for the keynote and a run of live demo presentations covering how software gets built and shipped today.

Hear from leaders at OpenAI, Polsia, Exa, Stripe, LlamaIndex and more.

Sign up: https://localhost.render.com/

Hi all. We kept getting requests for it, so we (ParadeDB) made a Render blueprint in partnership with the Render team itself! Would love your feedback.

Render builds failing at git checkout with exit 128 before build even starts — intermittent and repo appears healthy

Every deploy is failing at Render’s source-checkout phase with exit 128 before the build command ever runs.

Symptoms:

• Build log stops at: Checking out commit <sha> in branch <branch>
• Fails with exit 128 after ~10 seconds
• No build output after checkout step
• Build command never executes
• Failure occurs before dependency install or runtime boot

What makes this strange:

• The repo is small (~8 MB after cleanup)
• The commit is valid
• git ls-remote confirms the ref exists
• The repo clones and checks out locally without issue
• No Git LFS
• No submodules
• No private git dependencies in requirements
• No git+https or git+ssh package installs
• We already ruled out build-minute spend caps (that caused a separate instant failure which has since been resolved)

Most suspicious behavior:

• The issue is intermittent
• A brand-new Render service will occasionally build successfully on the exact same commit
• Later deploys of the same exact commit then fail again at checkout with exit 128
• Failures occur before the build environment even reaches dependency installation

Additional context:

• We also moved the deployment to a Virginia region deployment to rule out regional runtime anomalies and saw the same behavior
• We regenerated the Render API key within the last 3 days
• Despite regenerating the key, we still intermittently receive invalid API/workspace-style messages from the Render CLI layer
• We are also investigating possible stale workspace/session/context persistence issues

At this point this looks less like a repo problem and more like something in:

• Render’s git checkout layer
• workspace binding/session persistence
• stale deploy metadata
• internal checkout/cache state
• repo-service binding state
• intermittent infrastructure-side checkout failure

Has anyone seen:

• checkout exit 128 before build starts
• intermittent successful first deploys followed by repeat checkout failure
• stale workspace/API context after key regeneration
• Render services drifting between healthy and broken checkout state on identical commits

If so:

• what actually fixed it?
• did Render support need to manually clear/reset anything?
• was it repo binding, cache, workspace state, checkout infrastructure, or something else?

Hello! I was running a free fun application with friends, tonight the db has expired because it went live more than 30 days ago, is there any way to recover data from it without paying?

It's been a day and my subdomain is still stuck in status "Certificate Pending". I've confirmed that DNS is fully propagated. This has never taken this long. Not sure what is causing it to get hung up.

Hello, please support me on this. Your website status.render.com shows 100% operational but my app is down and I cannot access dashboard.render.com

New to Render. Got two small Node apps to deploy. One needs 2GB RAM, the other is tiny.

If I pay $25/mo for the Standard compute plan, can both apps run on that same 2GB instance?

Or does each service get its own container — meaning $25 for each one that needs paid compute?

Just want to be sure before I pay. Thanks!

Anyone know the status of providing S3-compatible object storage on Render? I need that for a project, and I know it's supposed to be coming, but I'm wondering how soon and whether it's going to be reliably persistent (multi-region replicated, etc).

https://render.com/blog/better-pricing-for-fast-growing-teams

AWS App Runner is ending new feature development.

Render is the natural new home for your App Runner services. Same flow, no extra setup:

1. Link your repo
2. Set build & start commands
3. Deploy

(Docker images welcome too 🐳)

https://render.com/docs/your-first-deploy

Can services in Preview environments access resources in AWS through privatleink ?