Most self-hosted Serverless stacks inherit the architecture of a public cloud:

• gateway

• scheduler

• control-plane services

• metadata database

• cache or queue infrastructure

• Kubernetes and operators

That architecture makes sense when the system must span regions, availability zones, and thousands of machines.

But what if the deployment target is one enterprise server, one workstation, or one air-gapped environment?

We built open-compute around that narrower constraint. It is a Cloudflare Workers-compatible platform where the runtime, control plane, scheduler, deployment authority, and product bindings are managed by a single Rust daemon.

SQLite owns the authoritative platform state. Local storage owns object bytes by default, with S3-compatible storage as an option. Deployments are immutable and content-addressed; promotion and rollback move a pointer instead of mutating an active deployment.

The result is one binary and no required Kubernetes, Redis, Postgres, service mesh, or external control plane.

Repo: https://github.com/elliothux/open-compute

This is not intended to replace a globally distributed platform. It is an experiment in what Serverless looks like when strong local consistency and infrastructure ownership matter more than global distribution.

I’m curious where people here draw the line:

At what scale does a distributed control plane become necessary, rather than inherited complexity?

I really like AWS Lambda Web Functions for running standard Node.js servers (Next.js standalone, Express, Nuxt) using native Node.js 24 HTTP execution—bypassing legacy event-trigger mapping (`event`, `context`, API Gateway JSON payloads) entirely, much like modern execution models (e.g., Vercel's Fluid Compute). However, putting CloudFront in front of it for static assets can get pricey on egress, and securing public Lambda Function URLs without CloudFront OAC can be awkward.

I built bestof2—an open-source CLI and GitHub Marketplace Action that automates a hybrid Cloudflare + AWS deployment:

* Pushes static build assets (`.next/static`, `public`, etc.) to Cloudflare Pages for $0 egress.

* Packages the server into an AWS Lambda Web Function running on native Node.js 24 HTTP (includes a 1-click CloudFormation template for least-privilege IAM + S3 bucket with 30-day lifecycle cleanup).

* Wires a Cloudflare Pages `_worker.js` to proxy non-static requests to the Lambda Function URL under a single unified domain (zero CORS issues).

* Locks down the public Lambda Function URL by injecting a shared `x-bestof2-secret` header at the Cloudflare edge and rejecting direct hits with a `403 Forbidden`.

* GitHub Repo: https://github.com/arcopscloud/bestof2

* GitHub Marketplace Action: https://github.com/marketplace/actions/bestof2-dual-cloud-deploy

* npm: https://www.npmjs.com/package/bestof2

If anyone else is running a Cloudflare-in-front-of-Lambda setup with native HTTP runtimes, how are you handling your origin auth and cold-start optimizations?

Quick PSA since it's this Friday. Per the Lambda runtimes page, python3.10 hits deprecation on Oct 31, 2026.

What that means in practice:

- Oct 31, 2026: AWS may stop applying security patches, and you can no longer create or update python3.10 functions in the console. CLI, SAM, CloudFormation and the Serverless Framework still work.

- Jul 29, 2027: creating new python3.10 functions is blocked.

- Aug 31, 2027: updating existing python3.10 functions is blocked.

- Existing functions keep running "as-is," with no patches.

- No extended-support fee for Lambda, unlike RDS/EKS.

To find affected functions (run per Region):

aws lambda list-functions --function-version ALL --query "Functions[?Runtime=='python3.10'].[FunctionName,Version]" --output text

If you're upgrading, python3.11 is still on Amazon Linux 2 and is deprecated Jun 30, 2027, so it's a short stop. python3.12+ runs on AL2023, so rebuild native deps and layers.

Disclosure: I put together a free AWS end-of-support tracker and wrote up the details, with links to AWS sources: https://eolwatch.pages.dev/guides/lambda-python-3-10-deprecation

Anyone hit anything nasty jumping to 3.12+?

Your Val Town account has been suspended for the following reason: This val aggregates multiple anonymous/keyless third-party AI chat APIs (Kilo, LLM7, G4F, DuckDuckGo) behind its own gate key, functioning as a resold AI-relay service rather than a real application. If you believe this is a mistake, please contact [email protected] to contest the ban.

I'm not selling anything. I'm simply trying to not pay 20 freaking dollars a question to the stupid ai monkeys

I got on discord and asked about this, the val town admin blocked me.

Not sure what to do other than talk shit about their b***h a**

A week out, so figured it's worth a heads-up for anyone still running python3.10 functions.

Per the Lambda runtimes page:

- Oct 31, 2026: python3.10 is deprecated. No more security patches, and you can't create or update python3.10 functions in the console (CLI/SAM/CloudFormation still work for now).
- Jul 29, 2027: creating new python3.10 functions is blocked.
- Aug 31, 2027: updating existing python3.10 functions is blocked.
- Existing functions keep invoking. They just run unpatched.

Find them (per Region):

aws lambda list-functions --function-version ALL --query "Functions[?Runtime=='python3.10'].[FunctionName,Version]" --output text

Upgrade notes:
- python3.11 is still on Amazon Linux 2 and is deprecated Jun 30, 2027, so it buys you very little time.
- python3.12+ runs on AL2023. Rebuild any layers or native deps (numpy, cryptography, psycopg, etc.) for the new base image.
- distutils is gone in 3.12, and cgi/crypt/telnetlib are gone in 3.13.
- If you deploy with SAM/Serverless Framework/CDK, bump the runtime in your template and check your bundling image matches.

Disclosure: I run a free AWS end-of-support tracker and wrote this up with links to the AWS sources: https://eolwatch.pages.dev/guides/lambda-python-3-10-deprecation

Anyone already moved to 3.13 or 3.14? Any cold start or packaging surprises?

Wanted to see if other people could find this useful, and maybe give me some advice.

Built a super simple way to give your coding agent an isolated machine on AWS. send it off to clone a repo, install dependencies and run tests while you do something else. if it wrecks the environment, delete the VM and move on. It comes with a CLI, Python SDK and MCP server.
You can just ask your agent to set it up :)

github.com/jnh12/agent-microvm

Setup: an LLM gateway on Lambda in front of Bedrock, finance wants cost per tenant, and the gateway assumes the Bedrock role per tenant with the tenant in RoleSessionName, so the caller ARN on the bill differs per tenant. The Bedrock docs warn that AssumeRole on every request can exceed STS rate quotas and say to cache credentials for the session lifetime. So: a module-scope cache.

On Lambda that is not one cache. Four documented facts change the arithmetic.

1. One execution environment per concurrent request. Objects declared outside the handler live only inside that environment, so a module-scope cache is one cache per environment, each starting empty.

2. Environments do not last. Lambda terminates them every few hours even for continuously invoked functions, and resets one after a failed invoke (timeout, crash, out of memory). The cache refills each time.

3. Sessions are capped. DurationSeconds defaults to 3600, and assuming a role from execution-role credentials looks like role chaining by IAM's definition, which caps a session at one hour. The IAM docs do not say this for Lambda outright, so test the session length.

4. The quota is shared. STS allows 600 requests per second per account per Region by default, across AssumeRole, GetCallerIdentity and the rest. Lambda assuming your execution role as a service principal does not count. Your gateway's AssumeRole calls do, along with every other STS call in that account and Region.

Put together, AssumeRole volume is not "one per tenant per hour". It is roughly concurrent environments x tenants each environment serves within a session lifetime, and it peaks exactly when Lambda scales out (up to 1,000 new environments every 10 seconds per function), all cold, all assuming at once. That is arithmetic from the docs, not a measured number; your figure comes from peak concurrent executions of the gateway function and the tenants active in one hour.

Two attribution bugs worth a grep:

• JS SDK v3 fromTemporaryCredentials (current README) generates a random RoleSessionName if you skip it. The call succeeds and the bill gets a random session name instead of a tenant.

• The Lambda docs say "Avoid global variables for context-specific information". A module-scope credential cache not keyed by tenant is exactly that: tenant A's session serves tenant B's call and the spend lands under the wrong tenant, with no error. In JS v3 the SDK caches credentials per client instance, so one fix is one Bedrock client per tenant per environment.

The per-environment cache is fine at low concurrency or with a handful of tenants. A cache outside Lambda cuts STS calls but puts live credentials in another service, which is a security decision, not a tuning one. Or drop per-tenant sessions and estimate per tenant from request metadata in invocation logs. Lambda Managed Instances serve concurrent invocations from one environment, so there the cache is shared and needs concurrency-safe code.

Lambda environment lifecycle: https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html STS quota: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html#reference_iam-quotas-sts-requests

If you run per-tenant STS sessions from a Lambda gateway, did you keep the cache per execution environment or move it out, and if out, where do the live credentials sit?

On 26-27 Aug 2025, my city (Jammu, India) got a record 296 mm of rain in 24 hours. Residents found out which streets were flooding from their neighbours, and the city had no ranked list of where to send pumps.

I built Tawi Twin for a hackathon: you ask “Kal Bhagwati Nagar mein paani bharega?” (Hinglish for “Will Bhagwati Nagar flood tomorrow?”), and an agent answers in your language with the risk, the reasons, what to do, and the nearest hospital and high-ground school.

Stack (all ap-south-1):

• Strands Agents with 7 tools, running in Lambda (arm64)

• Amazon Nova Pro on Bedrock for the agent and for vision triage of citizen photos

• API Gateway HTTP API, DynamoDB with TTL, EventBridge Scheduler for the hourly forecast refresh

• S3 + CloudFront serving 1,315 vector tiles for 188k buildings in 3D

• Amazon Location Service as the fallback geocoder, because OpenStreetMap doesn’t have Bhagwati Nagar or Gujjar Nagar

• Overture buildings from AWS Open Data, queried in place with DuckDB

• One SAM template for the whole stack

Things that bit me:

• sam build on Windows pulled the wrong wheels for Strands’ dependencies, so I vendored the package for aarch64 myself.

• apac. inference profiles need IAM permissions on both the profile ARN and the foundation-model ARN, and the AccessDenied error doesn’t say so.

• Nova sometimes leaks <thinking> tags (sometimes unclosed) into the final answer, and it ignored “reply in Hinglish” in the system prompt. I ended up detecting the language in code and stripping the tags.

• Presigned S3 uploads worked from scripts but failed in the browser until I signed against the regional endpoint.

• The API Gateway 29-second timeout limits multi-tool agent calls.

Does it work? Buildings near the 8 localities that reports named as flooded were about 1.5× more likely to be rated high risk than the city average. Four localities were clear misses, and they’re listed in the README. Eight places is a sanity check, not an accuracy score.

Blog write-up: https://builder.aws.com/content/3KV01tPoho6gi9F3plApVSr53Fp/kal-paani-bharega-teaching-a-city-to-answer-the-only-flood-question-that-matters-tawitwin
Code: https://github.com/Dupahar/TawiTwin
Live demo (hit “Replay the flood”): https://d2r8k00l2fxqnu.cloudfront.net

Happy to answer questions about the agent setup or the Windows packaging workaround.

For over two decades, agency hosting economics were beautifully predictable. You bought a reseller web server or dedicated cPanel account for $50 a month, crammed 30 client WordPress sites onto it, and charged each client a flat $25 monthly maintenance fee. Your margins were clear, your server bills were static, and billing surprises were virtually non-existent. Read the comple te article here > Serverless Bill Shock: Track Vercel & Supabase Client Costs | InstaRenewal

Then came the modern web stack.

Driven by the demand for lightning-fast digital experiences, agencies aggressively migrated to decoupled architectures: Next.js, Nuxt, Vercel, Supabase, Cloudflare Workers, and serverless databases like Neon. While the performance gains of this modern paradigm are undeniable, it introduced a chaotic operational reality: micro-subscription fragmentation and variable utility billing.

Hey All!

I created https://s8sskills.com as an open source repo for serverless skills for all the major vendors (so far). I really want to make this a bigger thing and am inviting everyone to participate and contribute their skills and really grow this project!

This year I decided to start my own online business. I'd never run my own business before and knew I wouldn't have much time to spend on it because I would have a full-time day job as well. I wanted something that had minimal running costs, low operational effort, and could scale if we were successful. I had no idea how well it would do, so I didn't want to invest a heap of time and money for no reason.

What went well

Spending time on high-quality steering docs for Kiro - We took a spec-driven approach to development with Kiro. Taking time to plan and design the features, then letting Kiro do a lot of the code generation, with us reviewing.

Static public pages / Dynamic pages once logged in - Like everyone, we worried about running away costs. Before logging in, the website is almost static; it doesn't hit Lambda functions or databases. Once you're logged in with Cognito then we feel safer from a cost point of view.

Costs are extremely low - Our highest costs are WAF ($1/day) and CloudWatch ($1/day). We're happy that we're getting good value and protection for our APIs, and observability/alarms are good enough.

Video streaming - Bandwidth costs for high-quality video were much lower than expected.

Lambda - Just great, a rounding error on the bill, no operational effort, and just works.

What we would change

DynamoDB - We started building everything with DDB, and we didn't know our business well enough; this made it difficult to change the model when the business changed. We would have been better off starting with DSQL and moving specific bits to DDB when required.

I spoke about everything in depth with Jullian Wood on Serverless Office Hours - https://www.youtube.com/watch?v=irtcYhgQ-vA

I've been building AI backends for a while and kept writing the same glue code — a Lambda that parses LLM output, maps tool calls to functions, handles retries, formats responses. None of it was the actual product.

Recently tried AWS Bedrock AgentCore Gateway to see if it could replace that layer. Turns out it can. You describe your Lambda as a tool in CDK, and AgentCore exposes it as a fully compliant MCP server — `tools/list`, `tools/call`, JWT auth included. No JSON-RPC code, no routing logic.

Wrote up the full walkthrough: stack definition, deploy steps, real curl commands against the live endpoint, and a few gotchas I hit along the way (the event shape isn't what the docs imply, and tool names get prefixed in a way that'll bite you the first time).

https://medium.com/itnext/your-lambda-functions-are-now-mcp-tools-heres-how-d715943d29bf?sk=c96c4eb525099fba247a0e190e839a82

Happy to answer questions — still exploring what else AgentCore can do.

We started using Lambda the right way — async, event-driven, retry-friendly workloads. Then it slowly crept into latency-sensitive API paths. That's when things got messy.

What we ran into:

- Cold starts hitting user-facing requests on low-QPS and spiky-traffic APIs

- One-invocation-per-environment model quietly exhausting downstream connection pools at scale

- Provisioned concurrency helping, but shifting us back into capacity planning territory

- VPC attachment adding more operational complexity than we'd accounted for

- Observability gaps — healthy invocation rate ≠ healthy service

The fix wasn't "stop using Lambda." It was getting honest about which workloads need elasticity vs. which need predictability. Those are different requirements, and the same execution model doesn't serve both.

Last quarter, we decided to measure something systematically that we'd been seeing anecdotally: the actual TCO difference between traditional cloud architectures and serverless edge platforms.

We applied a structured framework comparing infrastructure, operations, and deployment costs across both models.

What we found:

Organizations that moved from provisioned capacity to usage-based serverless edge architectures saw:

• 65% reduction in infrastructure costs

• 87% fewer maintenance hours

• 68% lower deployment effort

The key insight wasn't that edge is "cheaper" than cloud—it was that architecture matters more than location.

Why this happens:

1. Elimination of provisioned capacity overhead - You stop paying for idle

2. Reduced operational burden - No more server management, patching, scaling configuration

3. Deployment simplicity - Single deployment target instead of multi-region orchestration

4. Request resolution closer to users - Less dependency on centralized infrastructure

We published a whitepaper with the complete framework we used to calculate this, including where costs actually hide in traditional architectures and how to measure this in your own environment.

Questions for the community:

• Has anyone else measured TCO when moving to serverless edge architectures?

• What cost categories surprised you most in your own migrations?

• For those running hybrid architectures, where do you see the biggest inefficiencies?

Whitepaper link: https://www.azion.com/en/lp/tco-centralized-cloud-vs-serverless-edge-platforms/

The short version: a Lambda function can now checkpoint its state, sleep for hours or days, and resume exactly where it left off — without paying for idle time.

I rebuilt a human-in-the-loop expense approval workflow to test it. Before: Lambda + DynamoDB + Step Functions + SQS + EventBridge. After: two Lambda functions and an API Gateway.

The function literally looks like this:

```ts

const decision = await context.waitForCallback(

'wait-for-approval',

async (callbackId) => sendApprovalEmail(expense, callbackId),

{ timeout: { hours: 24 } }

);

```

It pauses there. Zero compute. Waits up to 24h for someone to click approve. Then resumes on the next line.

Wrote up the full architecture, CDK stack, and where Step Functions still wins:

https://medium.com/itnext/is-step-functions-still-necessary-the-case-for-lambda-durable-functions-in-2026-22f5a5f4a1a3

Happy to answer questions about the implementation.

The core idea: LLM generates a JSON DAG upfront,

pure TypeScript executes it — no LLM in the action loop.

- Claude Haiku plans, Sonnet summarizes

- 14 MCP microservices as the tool mesh

- Stateful HITL via DynamoDB

- 100% pass rate across 11 real-world scenarios

GitHub: https://github.com/sujithpvarghese/bedrock-agent-orchestrator-planner-executor

Happy to answer questions on the architecture.