Operating serverless functions in production means owning more than the function code. A reliable production function also needs controlled configuration, scoped credentials, observable invocations, safe retries, versioned deployments, rollback, cost limits, and a recovery path for failed events.
Raff Technologies Functions currently provides standard handlers, HTTP endpoints, cron schedules, one-off future runs, object-storage triggers, scoped database and storage bindings, logs and metrics, immutable revisions, rollback, scale-to-zero, spend caps, and long-running execution. The application team still owns workload-specific correctness: authentication, idempotency, data consistency, retry semantics, and incident decisions.
This guide is the LC12 operations connector. It does not replace the dedicated security, observability, database, deployment, or incident-response guides. It defines how those responsibilities fit together.
Production ownership starts with the trigger
Every function should have a clearly defined trigger and failure model.
Common Raff Functions triggers include:
- HTTP requests;
- timezone-aware cron schedules;
- one-off future runs;
- object-storage events such as uploads with prefix filters.
For each trigger, document:
- who or what can invoke it;
- whether duplicate invocation is possible;
- what data the function reads;
- what state it changes;
- what the caller expects on failure;
- whether retries are safe;
- how to disable the trigger during an incident.
A function that can be invoked but cannot be safely retried is not production-ready.
Keep handlers portable and configuration external
Raff Functions supports standard handlers such as FastAPI/ASGI, Node.js HTTP, Web Fetch, Go net/http, and a Dockerfile path for other runtimes.
Keep business logic independent from provider-specific trigger objects where practical.
Use:
- environment variables for non-secret configuration;
- masked secrets for sensitive configuration;
- scoped database and object-storage bindings instead of copying primary credentials into source code.
This improves portability and reduces credential blast radius.
For the portability model, use Portable Serverless Handlers: Avoiding Lambda Lock-In.
Use scoped bindings instead of shared master credentials
A function should have only the credentials it needs.
Raff currently supports per-function bindings for:
- managed databases;
- object-storage buckets.
The product injects scoped credentials so the function does not need the main account credential.
That makes rotation and revocation easier.
A thumbnail function, for example, should not automatically receive write access to every bucket and database in the account.
Treat every public HTTP function as an API endpoint
A public function URL needs the same security reasoning as any internet-facing API.
Consider:
- authentication;
- webhook signature verification;
- CORS;
- rate limiting;
- request-size limits;
- input validation;
- replay protection;
- idempotency.
Do not rely on an unguessable URL as authentication.
Use Serverless API Security: Authentication, CORS & Rate Limiting for the endpoint-specific security model.
Make retries explicit
Retries can happen because of:
- client retries;
- upstream retries;
- event redelivery;
- operator replay;
- deployment interruption;
- transient dependency failures.
Important functions should be designed to tolerate duplicate execution.
Useful controls include:
- event IDs;
- idempotency keys;
- database uniqueness constraints;
- processed-event tables;
- conditional writes;
- deterministic output keys.
A webhook that charges a customer twice because the sender retried the event is a correctness failure, not a platform failure.
Logs and metrics need a purpose
Raff Functions currently includes logs and metrics without a separate observability product charge. The live product exposes invocation count, latency percentiles, error rate, and per-request log correlation.
For each production function, decide which signals indicate:
- healthy operation;
- degraded performance;
- functional failure;
- runaway retries;
- unexpected cost growth.
At minimum, watch:
- invocation count;
- error rate;
- p50/p95 latency;
- recent logs;
- resource usage;
- spend-cap behavior where relevant.
Do not log secrets, access tokens, full authorization headers, or sensitive payloads.
Long-running functions need durable progress
Raff Functions supports longer execution than many traditional FaaS platforms: up to one hour by default and up to 24 hours on request.
Long runtime does not remove the need for recovery design.
For ETL, AI inference, imports, and batch jobs, persist progress outside process memory when restarting from zero would be expensive.
Possible durable state includes:
- database job record;
- object-storage output manifest;
- checkpoint key;
- completed-chunk table.
Use Long-Running Serverless Functions for AI, ETL, and Batch Jobs for workload fit.
Version every deployment
A production function should have a traceable deployed revision.
Raff Functions currently supports immutable revisions and one-click rollback.
Before a deployment, know:
- current revision;
- new revision;
- configuration changes;
- secret/binding changes;
- rollback target;
- whether the data schema is backward-compatible.
Code rollback cannot undo irreversible external side effects.
Separate code rollback from data recovery
A function rollback can restore a previous code revision.
It cannot automatically reverse:
- deleted objects;
- duplicate payments;
- already-sent email;
- committed database writes;
- external API changes.
For side-effecting functions, recovery design should include compensating actions or idempotent operations.
Use the spend cap as a safety control
Raff Functions meters memory and active CPU. Requests and function egress are currently free, and a per-account spend cap is enabled by default.
The spend cap is useful protection against runaway invocation or unexpectedly expensive workloads.
Still monitor workload behavior. A function pausing because of a spend cap can itself become an availability incident.
Cost control should combine:
- sensible memory/timeout settings;
- scale limits;
- optional warm instances only when justified;
- bounded retries;
- workload monitoring;
- spend cap.
Know when to disable a trigger
During an incident, continuing to invoke broken code can make the problem worse.
Examples:
- webhook handler corrupts records;
- object-storage trigger creates an event loop;
- cron job repeats a destructive operation;
- long-running import writes invalid output.
An incident runbook should distinguish:
- disable or stop the trigger;
- preserve evidence/logs;
- identify affected events;
- roll back code if needed;
- repair durable state;
- replay only safe events;
- re-enable gradually.
Production readiness checklist
Before relying on a function:
- trigger ownership is documented;
- authentication/signature checks are defined;
- duplicate execution is safe;
- secrets are not stored in source code;
- bindings are least-privilege;
- logs avoid sensitive data;
- health signals and alerts exist;
- timeout/memory/concurrency match the workload;
- spend controls are enabled;
- deployment revision is identifiable;
- rollback target exists;
- side effects have a recovery strategy;
- long jobs persist progress where needed;
- operators know how to disable the trigger.
Frequently asked questions
What does it mean to operate serverless functions in production?
It means owning trigger security, configuration, credentials, retries, observability, cost controls, deployments, rollback, and recovery in addition to the function code.
Are serverless functions maintenance-free?
No. The platform removes server management, but application correctness, secrets, retries, monitoring, deployment safety, and incident response still belong to the team.
How should serverless functions store secrets?
Use masked secrets or scoped service bindings rather than hard-coding credentials in source code.
How do I prevent duplicate function side effects?
Use idempotency keys, unique event identifiers, database constraints, and durable processed-event records so the same event can be handled safely more than once.
What should I monitor for a function?
Track invocation count, latency, errors, logs, resource usage, and workload-specific business outcomes.
When should I roll back a serverless function?
Roll back when the new revision creates a clear regression and the previous revision remains compatible with current data and configuration. Data-side recovery may still be required.
Sources
