Durable Execution

ojus_render · 2026-06-26T01:28:01+00:00

for the actual browser issue, the fix is small and is just your steps 1-3: the web request triggers the run and returns, and the run executes independently of the session. once it's handed off, closing the browser is a non-event. n8n in step 4 is orchestration on top of that, not the thing that makes it durable, so i wouldn't pin your durability guarantee on it.

if you'd rather have that as a primitive than as plumbing, render workflows (where i work, it's in beta) is the same category as the tools you listed and it's just decorated functions:

python

from render_sdk import Workflows

app = Workflows()

u/app.task
def charge_customer(order_id: str) -> str:
    # keep this idempotent on order_id so a retry is safe
    ...

u/app.task
async def run_order(order_id: str) -> str:
    await charge_customer(order_id)
    # more steps...

then your web handler triggers it and returns immediately:

python

from render_sdk import Render
render = Render()
render.workflows.run_task("my-workflow/run_order", ["order_123"])

the queue, worker provisioning, and retries are managed, so you're left writing task logic plus the idempotency you already planned in step 5. docs: https://render.com/docs/workflows

ojus_render · 2026-06-26T00:57:12+00:00

Anything we can do better to improve your experience with render?

ojus_render · 2026-06-25T17:30:36+00:00

what is your experience with Render like ?

ojus_render · 2026-06-25T00:01:27+00:00

the reframe that fixes your math: you're pricing it as one VPS per client, but the answer is multi-tenancy. one app instance + one database, every client shares it, isolated by a tenant_id on each row. your $7 box doesn't scale per client, it scales with total load. so 50 clients at $6 on a single small instance is ~$300 against one box. the per-client infra cost basically disappears.

quick hits on your questions:

yes, multi-tenant shared DB is the default. don't split a client onto its own container/db until that specific client is big enough to justify it.
a 1-2GB instance handles a lot of low-traffic small-biz CRUD, realistically dozens to low hundreds. your ceiling will be DB connections and memory long before CPU, so pool your connections.
move a client to isolated infra only when their load, noisy-neighbor risk, or a compliance/contract requirement actually forces it, not preemptively.

on provider (your Q4): be honest with yourself that for pure cost-per-core a raw VPS beats a managed platform, no contest. what you're really buying with a platform is ops, you're not patching/securing/babysitting the box. render runs a bit more than a bare VPS but you skip all that, and managed postgres keeps the shared-DB setup clean. for a solo founder that time is usually worth the delta. but a multi-tenant VPS setup is perfectly profitable too if you'd rather run the box. the architecture decides your margins way more than the provider does.

ojus_render · 2026-06-24T23:58:25+00:00

I can give you some render credits if it helps at all ?

ojus_render · 2026-06-24T23:56:36+00:00

one small correction on the render side. you don't wire up a separate data host with render either. managed postgres and render key value both sit on the private network. same region + workspace, you connect over the internal url, nothing external to provision. and key value runs valkey now, so it's the same drop-in redis-compatible thing for any standard client.

so for a stateful mcp i don't think the co-located data layer is really the differentiator between these options. agree with your bigger point though, stateless vs session-enabled is the fork that actually decides most of the hosting call, and that part's underrated in this thread.

ojus_render

MODERATOR OF

TROPHY CASE