Most serverless teams have their deployment pipeline sorted and their dev loop stuck in 2019: change a line, run serverless deploy function, wait ninety seconds, squint at CloudWatch, repeat. That loop is where the hours actually go. Serverless Framework V4 ships a dev mode that removes almost all of it, and there are two other tools worth knowing for the cases where it does not fit. This post covers all three and when to reach for each.
The three inner loops
| Approach | What runs where | Best for |
|---|---|---|
serverless dev | Real AWS event sources, your code on your laptop | Anything touching real AWS services: SQS, EventBridge, S3, DynamoDB Streams |
serverless-offline | Everything local, API Gateway emulated | Fast HTTP iteration, offline work, frontend devs who need a local endpoint |
serverless deploy function | Everything in AWS | Final verification, packaging and runtime issues, IAM behaviour |
They are complementary. Teams we work with usually end up using serverless dev for backend work, serverless-offline for anyone building against the API, and a deploy to an ephemeral stage in CI as the gate.
Dev mode: serverless dev
Run it from a service directory:
serverless dev --stage dev-alice
What happens: the framework deploys a lightweight shim in place of each of your handlers and opens a connection back to your machine. When a real event arrives — an HTTP request through API Gateway, an SQS message, an S3 notification — the shim forwards the event payload to your laptop, your local code executes it, and the response travels back to AWS. Logs and console.log output stream straight into your terminal. Save a file and the next invocation uses the new code; there is no redeploy.
The important consequence: the event sources are real. You are not guessing at the shape of an EventBridge envelope or an S3 record. Your code runs against real DynamoDB tables, real Secrets Manager values, and real payloads from every producer that already points at that stage.
A few practical notes.
Always use a personal stage. Dev mode replaces the deployed handler code with the shim, so never point it at a shared stage:
provider:
name: aws
stage: ${opt:stage, 'dev-local'}
Give every engineer their own (dev-alice, dev-bob). One shim per developer, no collisions, and serverless remove --stage dev-alice cleans it up.
Exit cleanly. When you stop dev mode with Ctrl+C it restores the real handler code. If the process is killed hard, the shim can be left behind and the stage will look broken; a redeploy of that stage fixes it. Do not let this happen on anything shared.
Credentials differ from Lambda's. In dev mode your handler runs with your local AWS credentials, not the function's execution role. Code that works in dev mode can still fail once deployed because the role is missing a permission. Keep a real deploy in the loop before merge, and keep least-privilege roles defined in serverless.yml rather than relying on what your laptop can reach — see least-privilege IAM and secrets.
Timeouts and memory are not simulated. Local execution is not bounded by the function's timeout, and there is no memory ceiling. Performance numbers from dev mode are meaningless; use a deployed stage for that.
serverless-offline, for a fully local HTTP loop
When you want an endpoint on localhost with no AWS involvement — on a plane, in a locked-down environment, or so a frontend developer can run the API without an AWS account — use serverless-offline:
npm install --save-dev serverless-offline
plugins:
- serverless-offline
custom:
serverless-offline:
httpPort: 4000
reloadHandler: true # re-require handlers on change
serverless offline --stage local
It emulates API Gateway (REST and HTTP API) and Lambda invocation locally. Pair it with containers for the stateful pieces — DynamoDB Local or LocalStack — so nothing reaches out to AWS, and switch endpoints with a single environment variable rather than branching on IS_OFFLINE through your business logic:
// src/lib/ddb.js
import { DynamoDBClient } from '@aws-sdk/client-dynamodb';
const endpoint = process.env.DYNAMODB_ENDPOINT || undefined; // unset in AWS
export const ddb = new DynamoDBClient({ endpoint });
The trade-off is fidelity. The emulator is not API Gateway: authorizers, request validators, mapping templates, WAF rules, custom domains, and throttling all behave differently or not at all. Treat a passing local run as "my handler logic is right", never as "this will work deployed". Our testing guide covers where LocalStack fits alongside this.
Tailing logs and invoking remotely
For the deployed loop, three commands cover most needs:
# Stream a function's logs
serverless logs -f api --tail
# Invoke deployed code with a saved event fixture
serverless invoke -f worker --path events/sqs-message.json
# Run the handler locally against the same fixture
serverless invoke local -f worker --path events/sqs-message.json
Keep an events/ directory of real payloads captured from CloudWatch, one per event source. They double as test fixtures, and serverless invoke local is the fastest possible loop for a non-HTTP function.
Making the loop reproducible for the team
Two files do most of the work of onboarding.
A stage-parameterised config, so a personal stage needs no edits:
params:
default:
logLevel: debug
tableName: app-${sls:stage}
prod:
logLevel: warn
tableName: app-prod
provider:
environment:
LOG_LEVEL: ${param:logLevel}
TABLE_NAME: ${param:tableName}
Scripts that name the loop, so nobody has to remember flags:
{
"scripts": {
"dev": "serverless dev --stage dev-$USER",
"offline": "serverless offline --stage local",
"logs": "serverless logs -f api --tail --stage dev-$USER",
"teardown": "serverless remove --stage dev-$USER"
}
}
Add npm run teardown to your team's definition of done for a branch. Abandoned personal stages are a common source of surprise line items on a serverless bill, and of log groups and API Gateway limits filling up a sandbox account.
Guardrails worth putting in place
- Block dev mode against production. A check in your scripts, or a developer role that can only assume into the sandbox account, stops the worst accident. See multi-account stage isolation.
- One AWS sandbox account for all personal stages, separate from staging and prod, with a budget alarm on it.
- Auto-expire personal stages. A scheduled job that removes stacks tagged
stage-type=personaland untouched for fourteen days keeps the account tidy. - Do not let dev mode replace real testing. It shortens the feedback loop; unit tests and an ephemeral-stage deploy in CI still decide whether the change is correct.
Choosing, in one line each
Use serverless dev when the thing you are debugging involves a real AWS event or service. Use serverless-offline when you need a local HTTP endpoint and nothing else. Use serverless invoke local with a saved fixture for pure handler logic. Use a deployed ephemeral stage before you merge, every time.
We set this loop up as part of most DevOps for Serverless Apps engagements, usually in the first week, because everything after it goes faster. If your team is still redeploying to test a one-line change, get in touch.