DEV Community: Yura Oak

Claude Code --dangerously-skip-permissions: usage and limits

Yura Oak — Wed, 07 Oct 2026 13:13:40 +0000

claude --dangerously-skip-permissions starts Claude Code in bypassPermissions mode. It removes routine approval prompts for file changes, shell commands and tool calls. Use it for a bounded task inside a disposable environment whose files, credentials and network access you have already limited. The flag itself creates no sandbox.

claude --dangerously-skip-permissions

That is the command. Before adding it to an unattended job, check what the process can reach. A missed approval on a throwaway checkout has a different cost from a missed approval on a laptop that holds production credentials.

This guide covers the command, alternatives and a concrete run-and-review workflow. We checked Anthropic's documentation on October 6, 2026. The examples describe a setup; they are not results from a live Claude Code security test.

What does dangerously-skip-permissions do?

The flag selects the same permission mode as claude --permission-mode bypassPermissions. Claude can continue working without the usual approval stops. It keeps the operating-system identity and access of the process you launched: it does not grant root privileges, invent credentials or create access to a network your environment blocks. Claude Code permission modes.

There are still exceptions. Current releases retain explicit deny rules and ask rules, checks for certain critical-path removals, and actions that require user interaction. Do not treat those exceptions as protection for arbitrary files or cloud resources. A command can harm a project without deleting a filesystem root.

In particular, bypass mode can write to .git and .claude without the protected-path prompt. Some search summaries suggest that these folders always stay protected. That is not what the current documentation says. Permissions reference.

Consider a routine request: “Fix the failing tests.” Claude might edit a test, install a package or change configuration. If the same process can also read a cloud key and call its API, a disposable local folder alone does not restrict those remote actions. Your setup must limit that access before the run begins.

Commands for interactive and unattended use

Start an interactive session

Open a terminal inside your prepared environment and run:

claude --dangerously-skip-permissions

Check the displayed permission mode before giving the task. On the first interactive launch, Claude Code can show a warning that you must accept. For a root or sudo error, use a non-root account inside the environment instead of changing the host's protections. Mode setup and root restrictions.

Run one task and capture its result

For a current Claude Code release with API-key authentication:

claude --bare -p \
  "Fix the failing unit test in this checkout. Run the relevant tests. Report changed files and failures. Do not commit or push." \
  --dangerously-skip-permissions \
  --max-turns 12 \
  --output-format json > /tmp/claude-result.json

Here, -p runs a non-interactive task, and --output-format json makes its response easier for a runner to collect. --max-turns limits the agent loop; it does not impose a wall-clock deadline on the whole job. Configure that deadline in your runner too. CLI flag reference.

--bare avoids loading the usual ambient hooks, plugins, memory and repository instructions. For Anthropic's API it needs ANTHROPIC_API_KEY; it does not use your subscription's OAuth login. Supply that key through the runner's secret settings. On older releases, check support before copying this example. Programmatic runs and bare mode.

The prompt's “Do not commit or push” describes the task. Enforce the restriction by withholding write access to the remote repository. A sentence in a prompt cannot replace a credential scope or network policy.

For more on collecting results and handling failed jobs, see our Claude Code headless guide.

Enable bypass for later in the session

The similarly named flag has a different effect:

claude --permission-mode default --allow-dangerously-skip-permissions

--allow-dangerously-skip-permissions makes bypass selectable later; it does not start in bypass. Use the terminal's Shift+Tab mode cycle to switch. If the session did not enable bypass at launch, restart with the enabling flag. CLI reference.

Auto mode vs dangerously-skip-permissions

Choose the least permissive mode that lets the task finish:

Mode	Approval behavior	A practical use
`default`	Manual approval for actions that need permission	Work involving sensitive files or shared systems
`acceptEdits`	Approves file edits and common filesystem operations	Local coding with review of other actions
`auto`	A classifier reviews actions beyond routine approvals	Longer coding tasks with fewer interruptions
`dontAsk`	Denies actions that would need a prompt	A job with a narrow set of allowed tools
`bypassPermissions`	Skips routine checks, with documented exceptions	A bounded job in an isolated environment

The mode names and behavior come from the permissions reference.

Auto mode uses a separate classifier to review actions such as shell commands and external tool calls. It can block an action and let Claude try another approach. It can also make mistakes. Anthropic describes it as a way to reduce approval overhead, with tradeoffs that manual review and bypass do not share. How Anthropic built auto mode.

If repetitive prompts are your main problem, start by trying auto mode where your account supports it:

claude --permission-mode auto

If your job only needs known tools, consider dontAsk with narrow allow rules. It has a useful property for automation: missing permission fails the action instead of leaving the job waiting for a person. Inspect denied actions before widening the rules.

Does Claude Code's sandbox make bypass safe?

Claude Code's built-in Bash sandbox restricts shell access to files and the network. Its auto-allow option can approve sandboxed commands without a prompt. That option is separate from auto mode's classifier. Bash sandbox configuration.

The built-in Bash sandbox does not contain the whole application. File tools, MCP servers and hooks need their own boundary, or an outer environment that contains the entire Claude Code process. A VM and a container also provide different isolation. Choose based on what code you intend to run and what failure you can tolerate. Sandbox environment comparison.

Check the retry behavior too. With bypass enabled, an unsandboxed retry can run without asking. For supported setups, the following sandbox settings prevent that retry and require the sandbox to start:

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

Review any excludedCommands entries as well; they can still run outside the Bash sandbox. For centrally enforced settings, use managed policy that the agent cannot edit. Strict sandbox settings.

A practical workflow for an unattended run

Take a small failing-test task as an example. The output you want is a patch and a test report. There is no reason for this job to hold deployment access.

1. Prepare a separate checkout

Create a fresh container or VM and copy in the repository at a known commit. Prefer a copy to a writable mount of your main working directory. A worktree helps separate changes, but does not isolate the operating system or credentials.

Install the required runtime and packages during setup. Record the starting commit and tool versions. Use a non-root account for the agent. If you start with a dev container, inspect its mounts: a writable host directory exposes those host files to edits inside the container. Anthropic's dev container guide explains the setup and its limits.

2. Give the job only the access it needs

Pass the model credential separately. If the repository is private, use read-only repository access for checkout. Keep deployment keys, your SSH agent, the Docker socket and unrelated home-directory files outside the environment.

Allow the model endpoint and the package or source hosts the task needs. Restrict other outbound access in the environment's network controls. If a dependency download fails, identify the required host before opening more destinations.

This is also where you decide which MCP servers, if any, the task needs. A database or cloud MCP connection adds remote capabilities even when the local filesystem is disposable.

3. Run a task with a clear end condition

Use the headless command above once authentication and dependencies are ready. Put the job under a runner timeout and capture its exit status, stdout and stderr. Keep the test command under your control so that the result does not depend only on the agent's summary.

Start with a small change: one failing test or one documented bug. “Clean up the entire repository” leaves too much room for edits you did not intend to review.

4. Review the actual files

After the job ends, inspect the checkout:

git status --short
git diff --stat
git diff --check
git diff
git ls-files --others --exclude-standard

The last command lists untracked files, which a plain diff misses. Inspect them too. Compare the final commit with the starting commit so an unexpected commit does not hide changes from the working-tree diff. Re-run the relevant tests from your trusted runner, then review the patch before merging it.

Export the files you need before stopping the environment. Keep credentials out of logs and artifacts. Expire the task's credentials and destroy the disposable workspace after the review material is safe.

Running the task remotely

Lizard (lizard.build) offers Lizard Sandboxes, which can provide the remote workspace for this pattern: create an environment, execute a task, collect its files and stop it. Set an explicit lifetime so a failed runner does not leave the environment running indefinitely. Start with the Sandboxes quickstart.

Check the runtime before choosing it for your threat model. Lizard's documented default uses Kubernetes pods with runc and shares the host kernel. Firecracker support has a limited rollout for selected accounts and templates; do not assume that every sandbox uses a microVM. Use the runtime your account actually provides and keep credentials scoped accordingly. See the runtime documentation.

Remote execution helps when you need a fresh workspace for each job or many jobs at once. It still needs a network policy and a review step. A sandbox with a production database token can reach that database regardless of where the sandbox runs.

Frequently asked questions

Can I use dangerously-skip-permissions by default?

Yes. For a dedicated container or VM worker, merge this into that worker user's ~/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "bypassPermissions"
  }
}

New terminal sessions then start in bypass mode. Keep this default confined to the disposable worker; for individual jobs, use the explicit launch flag. In current releases, this value does not enable bypass from a repository's .claude/settings.json or .claude/settings.local.json. Managed policy may also disable the mode. Settings scope and precedence.

Do subagents inherit bypass permissions?

Yes. In the current documented behavior, a main conversation in bypass mode makes its subagents use the same mode, overriding their own permission-mode setting. A subagent is not a separate security boundary. Subagent permissions.

Why does Claude still ask a question?

An approval prompt and a question about the task are different. Some actions require interaction even in bypass mode, and configured ask rules can still apply. Read the actual prompt before assuming the flag failed. For unattended jobs, specify the expected output and failure behavior up front.

Does the flag make Claude Code free or remove rate limits?

No. It changes permission handling. Your model provider still controls authentication, usage charges and rate limits. Repeated retries can use more tokens even when no approval prompt appears.

For daily work, try auto mode or the Bash sandbox's auto-allow option first. For unattended bypass runs, make the environment disposable, restrict what it can reach, and review the resulting files before they affect your main project.

Originally published on Lizard.

Vercel Sandbox pricing: costs, limits, and alternatives

Yura Oak — Tue, 06 Oct 2026 08:17:45 +0000

Vercel Sandbox pricing depends on how much CPU your code uses and how long you keep memory allocated. In the default US region, Vercel charges $0.128 per active vCPU-hour and $0.0212 per GB-hour of memory. While your agent waits for an AI model, it can stop using CPU, but you still pay for its memory. See Vercel's pricing.

Lizard (lizard.build) has the lowest paid compute price of the four providers we compare here. For 10,000 five-minute runs with 2 vCPUs and 4 GB of memory, we calculate $7.50 on Lizard versus $92.01 on Vercel, assuming 10% CPU utilization. That's 91.8% less before credits, subscriptions and any extra storage or transfer charges.

We checked prices on October 5, 2026. This is a Lizard guide, so we're comparing our own product with other providers. We used their official prices and checked Lizard's rate against its billing data. The calculations assume the same stated CPU and memory sizes; actual throughput and reliability need separate tests.

Vercel Sandbox pricing by resource

The Pro rates below apply to iad1. If you plan to run elsewhere, check the regional prices: CPU, memory and some other charges change with location.

Charge	Published rate	What it means for your estimate
Active CPU	$0.128 per vCPU-hour	Count CPU execution across all allocated vCPUs
Provisioned memory	$0.0212 per GB-hour	Count allocated memory throughout the running session
Sandbox creation	$0.60 per million	Add the number of creation calls
Snapshot storage	$0.08 per GB-month	Add retained filesystem snapshots
Drive storage	$0.05 per GB-month	Add persistent drive data
Drive reads / writes	$0.0015 / $0.004 per GB	Add data read from or written to drives

Source: Vercel Sandbox rates and quotas. Vercel bills memory in minimum increments of one minute. That doesn't affect our five-minute jobs. If your job finishes in a few seconds, include the minimum in your estimate.

An agent waiting for an LLM may use little CPU. A compiler could use most of the available CPU during the same five-minute session. Vercel's explanation of Active CPU billing covers the difference between running code and waiting on I/O.

Record elapsed time and CPU time separately. A job that takes five minutes to finish won't necessarily use five minutes of CPU.

Is Vercel Sandbox free?

Hobby includes 5 active CPU hours, 420 GB-hours of memory and 5,000 creations each month. See the Hobby quotas. You also get 20 GB of data transfer. If you use up an allowance, Vercel pauses new sandbox creation until it resets. You can upgrade to Pro to keep running tasks.

A small project that qualifies for Hobby and stays within those allowances can cost nothing. Keep that in mind when comparing paid rates. The estimates below help you budget for usage beyond free allowances and trial credits.

How the Pro credit changes your bill

Vercel Pro costs $20 a month and includes one deploying seat and $20 in usage credit. You can spend that credit on eligible infrastructure across the account. Extra paid seats add to the bill.

If you use the account only for Sandbox, with one seat and no extras, the bill is:

Monthly Pro bill = $20 + max(0, eligible usage charges - $20)

With $9.20 of eligible usage, you pay $20. With $92.01 of usage, you pay $92.01. Simply adding $20 to your usage estimate would count the portion covered by the credit twice.

If you already pay for Pro, check how much credit your other services use. You may have enough left to cover a small sandbox workload. In that case, adding those tasks won't increase your bill.

Worked example: 10,000 agent tasks per month

Each task in this example creates a sandbox, runs for five minutes and stops. We use 2 vCPUs and 4 GB of memory per instance. Vercel runs in iad1, with CPU utilization averaging 10% across the allocation. Each job fits within 5 GB of local workspace storage.

We leave out model tokens, taxes, retained snapshots, persistent drives and billable network traffic. The example assumes a disposable workspace. If you need to keep the result, export it before stopping the sandbox and add any transfer charge to your estimate.

Using the published Vercel rates:

Elapsed sandbox hours = 10,000 × 5 / 60 = 833.333...
Active vCPU-hours     = 833.333... × 2 × 0.10 = 166.666...
Memory GB-hours      = 833.333... × 4 = 3,333.333...

CPU cost             = 166.666... × $0.128 = $21.333...
Memory cost          = 3,333.333... × $0.0212 = $70.666...
Creation cost        = 10,000 × $0.60 / 1,000,000 = $0.006
Vercel usage total   = $92.006, rounded to $92.01

Lizard Small         = 833.333... × $0.009 = $7.50

Most of the Vercel cost here comes from memory. Even if the agent used less CPU, that memory charge would remain. Lizard Small charges a fixed rate for the running sandbox, with CPU, memory and idle time included.

What changes as task volume grows?

Five-minute runs per month	Total sandbox hours	Vercel usage estimate	Vercel Pro bill, one seat*	Lizard running cost
1,000	83.33	$9.20	$20.00	$0.75
10,000	833.33	$92.01	$92.01	$7.50
100,000	8,333.33	$920.06	$920.06	$75.00

The Pro bill assumes the full $20 credit is available for these tasks and you incur no other charges. Lizard figures exclude trial credits. We use the same task duration for both providers; test your application to find out how long it takes on each.

You don't need a worker for every task. A small pool can process 100,000 tasks over time. If those tasks arrive at once and need an immediate response, check concurrency limits as well as monthly cost.

What if CPU usage is higher?

Keeping 2 vCPUs and 4 GB allocated for one hour gives these compute costs:

Average CPU utilization	Vercel CPU + memory	Lizard Small
0%	$0.0848	$0.009
10%	$0.1104	$0.009
50%	$0.2128	$0.009
100%	$0.3408	$0.009

Creation fees and extras sit outside this table. Lizard costs less at every CPU level shown, including when Vercel charges nothing for CPU. In that case, Vercel's memory charge alone exceeds Lizard Small's running rate.

Vercel Sandbox alternatives: compare the paid rates

The table compares the advertised 2 vCPU / 4 GB memory class on each service. E2B and Daytona price memory in GiB, so keep their units when working out your own bill.

Provider	Running rate for this allocation	Usage for 10,000 five-minute runs	Plan or allowance to consider
Lizard Sandboxes	$0.009/hour	$7.50	No monthly subscription; temporary trial credits excluded
Vercel Sandbox	$0.1104/hour at 10% CPU	$92.01 including creation calls	Pro fee and credit as explained above
E2B	$0.1656/hour	$138.00	Hobby supports the default size; Pro adds $150/month for higher limits
Daytona	$0.1656/hour	$138.00	Temporary credits excluded; extra storage adds cost

The E2B and Daytona calculations use $0.0504 per vCPU-hour and $0.0162 per GiB-hour: 2 × $0.0504 + 4 × $0.0162 = $0.1656/hour. E2B publishes its rates per second; we converted them to hours. Their totals exclude storage or network charges beyond any included allocation.

For this paid workload, Lizard has the lowest price of the four providers. Your bill may differ if you have unused credits, qualify for free usage or negotiate a contract. Check the disk space and regions you need, along with the provider's security and lifecycle features, before choosing on price.

Lizard: a fixed rate for each sandbox size

Lizard Sandboxes has three size tiers:

Size	vCPUs	Memory	Local workspace storage	Running price
Small	2	4 GB	5 GB	$0.009/hour
Medium	4	8 GB	20 GB	$0.018/hour
Large	8	16 GB	50 GB	$0.036/hour

You pay by the second while the sandbox runs, including when it's idle. Each account gets up to 2 TB of sandbox egress over a rolling 30 days. Persistent Volumes cost extra. Standard accounts use pay as you go with no monthly subscription, and purchased credits don't expire. The pricing page lists the trial terms.

Lizard Sandboxes also support Firecracker microVMs for selected accounts and supported templates. Those microVMs each have their own kernel. Access is currently limited: the default runtime uses Kubernetes pods with runc and shares the host kernel. If your application requires a separate kernel, confirm which runtime your account can use before you choose a size or compare its cost.

Once you've checked the runtime and size, you can budget from the time your tasks take to run. Use Lizard CLI from your terminal, or call the API described in the Sandboxes documentation.

E2B: longer sessions can mean a Pro subscription

E2B's pricing page lists default-size sandboxes on Hobby, with sessions up to one hour and 20 concurrent instances. Pro adds custom CPU and RAM, sessions up to 24 hours, and higher concurrency for a $150 monthly fee plus usage.

Our short tasks fit Hobby's default size and session limit, provided you schedule them within its concurrency limit. If you need Pro, the same usage plus the base fee totals $288 before extras or credits. Our E2B sandbox guide covers the lifecycle details to check before choosing a plan.

Daytona: budget for the files you keep

Daytona lists CPU, memory and storage separately and bills by the second. Its first 5 GiB of storage are free; additional storage costs $0.000108 per GiB-hour. It also publishes GPU options.

Our example fits within the included storage. For a job with a large working directory, add the cost of the space it uses and the time you keep it. If the job needs a GPU, add that rate too.

When Vercel Sandbox is worth the higher paid rate

If your app already runs on Vercel, you may prefer to keep its sandbox tasks in the same account and tools, especially when unused credit covers them. Moving providers means spending time on authentication, retries and file handling. Include that work in the decision.

Vercel has 19 regions and region failover on paid plans. If your agent needs to run near your users or data, check those locations before comparing hourly rates.

Vercel runs sandboxes in Firecracker microVMs. Its persistent sandboxes save the filesystem when they stop and restore it for the next session. Check whether your application needs those files or also needs to preserve running processes.

The current quotas permit 45-minute sessions on Hobby and 24-hour sessions on Pro, with up to 10 and 10,000 concurrent sandboxes respectively. The Pro limit is 8 vCPUs and 16 GB memory per instance. Current SDK configurations include 64 GB of ephemeral disk, more than Lizard Small's 5 GB workspace. See Vercel's resource limits.

What to measure before switching

Run a task you expect to use often and record:

How long it takes to get a usable result, including setup, package installation and retries.
How much CPU time and allocated memory it uses, so you can calculate Active CPU charges.
Which files you keep afterward and what retention and recovery will cost.
How much network traffic it generates, including result downloads, preview ports and calls to other services.
How many tasks need to run at once and how long each session lasts. Check both against the account's limits.
Which runtime runs the task and what it can access. Give it only the credentials it needs.

Stop workers when they finish and remove stored data you no longer need. Vercel can still charge for snapshots after a sandbox stops. Lizard charges the size's running rate for as long as you leave it running, even when it's idle.

Try a small batch first. Divide its cost by the number of tasks that succeeded, then compare that figure with what you pay now before moving more traffic.

Start with a Small sandbox

For our paid task example, Lizard costs $7.50 against Vercel's $92.01. You can estimate its running cost from the size and duration alone. Firecracker support is available through the limited rollout described above.

If the runtime, disk space and account limits fit your project, try Lizard Sandboxes with one of your own tasks. Check the result and the charges. The pricing page covers the costs to include when you increase usage.

Originally published on Lizard.

Codex Exec: Automate Deployment Checks from the Terminal

Yura Oak — Mon, 28 Sep 2026 10:57:09 +0000

Originally published on Lizard (lizard.build).

codex exec runs Codex without the interactive terminal interface. Give it a prompt or pipe in data, then save the answer for your next script step. This guide builds a deployment report with JSONL events, a schema-constrained result and an exit code based on real HTTP checks.

You will test two versions of a small quote API: one works, and one returns HTTP 200 from its health endpoint while the quote route fails. The complete example includes the collector, report schema and validation script.

Run Codex without the interactive interface

From a trusted Git repository, run:

codex exec --sandbox read-only \
  "Summarize this repository in three sentences. Do not change files."

Codex writes progress to stderr and its final answer to stdout. You can redirect that answer to a file. The official non-interactive guide covers this behavior and the supported automation patterns.

For a deployment report, we will supply the observations on stdin. A small Python collector makes the network requests. Codex explains the evidence, and a separate function checks the report against those observations.

Understand the three output files

These files have different roles:

File	Contains	How to read it
`events.jsonl`	Run events from `--json`, one JSON object per line	Parse each nonempty line separately
`report.json`	Final answer written by `-o`, shaped by `--output-schema`	Parse one JSON object
`stderr.log`	Diagnostics from the CLI process	Keep it for troubleshooting

--json changes stdout into an event stream. It does not make the whole stream a single report object. --output-schema describes the final answer, and -o saves that answer separately. This distinction prevents a common automation bug: trying to parse the entire event log with one JSON read.

Prepare the example

Use Python 3.10 or later and an authenticated Codex CLI. The Python files need no third-party packages. The shell commands below target Bash or Zsh on macOS or Linux.

codex --version
codex login status
mkdir codex-deployment-check
cd codex-deployment-check
for file in demo.py collect.py gate.py run.py report.schema.json verify.py; do
  curl --fail --silent --show-error \
    "https://lizard.build/blog-examples/agent-deployment-checks/$file" \
    --output "$file"
done

Read the downloaded files before executing them. Start the demo and keep it running:

python3 demo.py --port 8787

The application has two GET routes. /healthz returns status: ok. /api/quote?quantity=3 calculates a quote for three items at 1,200 cents each. The expected result is $36.00 (3,600 cents). The example uses integer cents to avoid rounding in the assertion.

Open another terminal in the same folder for the remaining commands.

Collect and inspect the HTTP evidence

python3 collect.py http://127.0.0.1:8787 > evidence.json

The collector records the URL, check time, HTTP status and whether each response matches its expected fields. It makes two bounded requests, rejects redirects and caps each response at 64 KiB. It sends expected values and booleans to the model, without copying arbitrary response text.

For your application, replace the demo paths and expected values in both collect.py and gate.py. Choose a route that exercises useful behavior: calculate a price, read a seeded database record or fetch an existing document. Match the response content as well as the status code.

The collector's exit code says whether it collected evidence. A failed application check still produces an evidence file, so Codex can explain the failure. The final gate determines the job's result.

Request a structured report

From a trusted Git repository containing the files, run:

codex exec --ignore-user-config --ephemeral \
  --sandbox read-only \
  --json \
  --output-schema report.schema.json \
  -o report.json \
  "Explain the evidence on stdin. Use no tools. Copy its verdict, list failed check names in failed_checks, and give a summary and next_step. Do not infer a root cause from HTTP status alone." \
  < evidence.json > events.jsonl 2> stderr.log

If you use only the new download folder, add --skip-git-repo-check. The complete wrapper does so in a temporary directory made for the report. Use that flag deliberately when no repository is needed.

--ignore-user-config skips the user's main Codex configuration file while retaining normal authentication. --ephemeral prevents saving the session rollout. The shell still saves the three explicit output files above. --sandbox read-only limits model-generated commands; the shell's redirects write the artifacts.

The schema requires verdict, failed_checks, summary and next_step, and disallows extra fields. The report should explain what the supplied checks establish. A response can suggest inspecting application logs after a 503, but the status code alone does not prove a database failure.

Parse the stream and the final answer separately

In our live test, Codex emitted these event types in order:

thread.started
turn.started
item.completed
turn.completed

The completed item was an agent message. These particular runs made no tool calls. Other tasks can produce more events, including command executions, tool calls and errors; do not require every successful run to have exactly four lines.

The wrapper reads each event and rejects turn.failed or error. It also requires turn.completed, a successful process exit and a final report that parses. Then it compares the report's verdict and failed-check names with the HTTP evidence.

A stream that ends early is an incomplete job. A report file left over from a previous run is also unsafe to reuse. The wrapper creates a new output directory and refuses to overwrite an existing run.

Run the complete workflow

python3 run.py codex http://127.0.0.1:8787 runs/healthy

This command collects fresh evidence, launches Codex with a 180-second process timeout, saves its output and validates the report. The wrapper exits 0 only when both application checks pass and the report agrees.

To reproduce the failure, start a second demo in another terminal:

python3 demo.py --port 8788 --broken

Then run the same workflow against that instance:

python3 run.py codex http://127.0.0.1:8788 runs/broken

The health route returns 200 and the quote route returns 503. Codex receives those observations and returns a failure report. The wrapper exits 1. The reporting process can complete successfully while the application check fails; your automation must use the wrapper's exit code for the application decision.

Results from the working example

We ran both scenarios with Codex CLI 0.156.1 and Python 3.12.10 on September 28, 2026. We also checked the Lizard CLI commands against version 4.0.8.

Scenario	Health route	Quote route	Codex report	Wrapper exit
Working demo	200, expected body	200, $36.00 (3,600 cents)	`pass`, no failed checks	`0`
Broken quote	200, expected body	503	`fail`, `quote` failed	`1`

Both model calls completed and produced a report that matched the collected evidence. The broken-run report suggested reviewing logs at the recorded time. It did not claim that the health endpoint established full application health.

The local validation tests also reject a false success report and incomplete evidence. Run them without a model call:

python3 verify.py

This is a synthetic HTTP test on a local machine. It does not cover production traffic, public DNS, TLS, database migrations or every route. Add checks for the parts of your own deployment that matter.

Add Lizard service state and logs

For an application on Lizard, confirm the target before interpreting failures:

lizard skills get core --json
lizard status --json
lizard ps --project YOUR_PROJECT --json
lizard logs --project YOUR_PROJECT --service YOUR_SERVICE --tail 100 --json

Lizard CLI gives you machine-readable service information and a bounded log snapshot. The core guide matches the installed CLI version. Use it when you need more commands or flags, and use explicit project and service selectors in automation.

Run the adapted HTTP collector against the service's public URL. A container marked as running does not prove that a price lookup or database read works. Compare the HTTP failure time with the service logs to narrow the next investigation. Review and redact log content before sending it to a model.

If you need to deploy first, start with the coding-agent deployment guide. For apps with data dependencies, the Postgres MCP tutorial and Redis MCP tutorial explain scoped access for inspecting test data.

Use the result in automation

Keep three outcomes explicit: application passed, application failed, and report job failed. This wrapper uses 0, 1 and 2 respectively. A timeout, CLI authentication problem, invalid report or contradiction in the output produces code 2.

Store the evidence alongside the report. That lets a teammate verify the result without trusting a prose summary. Give scheduled runs distinct output paths, set a retention period and avoid storing credentials in artifacts.

On your own trusted machine, codex exec can reuse the saved CLI login. For GitHub Actions, follow the official Codex action guide for authentication and permission setup. Keep API credentials out of repository files and avoid exposing them to untrusted build steps. Review those runner-specific requirements before transferring a local command into CI.

Use fresh evidence for each independent check. codex exec resume can continue a conversation, but it is not needed for this one-shot report. The example's ephemeral mode makes each run independent.

Troubleshooting

Symptom	What to inspect
Not inside a Git repository	Run from the intended repository, or deliberately use `--skip-git-repo-check` for the isolated report folder
JSON parser reports extra data	Parse `events.jsonl` one line at a time; parse `report.json` as one object
No final report	Check the process exit, stderr and failure events
Wrapper exits 1 although Codex exited 0	The application check failed; inspect `failed_checks` and evidence
Wrapper exits 2	Check authentication, timeout, schema, contradictory output or an existing output directory
A hosted endpoint redirects	Verify the route and required authentication; this collector rejects redirects

Where to go next

Use this pattern for a focused deployment check, then add assertions for your application's real dependencies. Keep the checks small enough that a failed result points to a useful next step.

If your team uses Claude Code, the Claude Code headless guide shows the same HTTP checks with its result envelope. To run the application itself, use Lizard CLI and add the report after your deployment step.

Claude Code Headless: Check Your Deployment from the Terminal

Yura Oak — Mon, 28 Sep 2026 10:49:05 +0000

Originally published on Lizard (lizard.build).

Claude Code headless mode runs a prompt from your terminal with claude -p and exits when the task finishes. You can pipe in data, save the answer and call it from a script. This guide uses it to explain deployment checks: a health endpoint, a price quote and a report that your script can verify.

The example catches a common failure: /healthz returns HTTP 200 while a real application route returns 503. You will get a reproducible demo, a JSON report and a nonzero exit code when the application check fails.

Start with one non-interactive command

With Claude Code installed and signed in, run:

claude -p "Explain what an HTTP 503 response tells me in two sentences." \
  --tools ""

-p means print the result and exit. --tools "" disables the built-in tools for this question. Claude can answer from the prompt without reading your repository or running a shell command. The Claude Code CLI reference lists the available flags.

For a deployment check, give the model observations that your script has already collected. This makes each HTTP request and pass condition easy to inspect. It also keeps deployment credentials out of the model's input.

What you need

Use Python 3.10 or later, a current Claude Code installation and an authenticated account. The demo uses Python's standard library, so it has no Python packages to install. Run the shell examples in Bash or Zsh on macOS or Linux.

Check the installed CLI and its authentication state:

claude --version
claude auth status

If a request fails because the saved session has expired, run claude auth login and retry. A saved login can exist even when the next API request cannot refresh it.

For the optional hosted checks, install Lizard CLI and sign in to your own project. If you still need to deploy your application, follow Deploy from Claude Code first.

Download the example and start the demo

Create a new folder and download the six files. Read them before running them. The demo accepts GET requests and keeps no customer data.

mkdir claude-deployment-check
cd claude-deployment-check
for file in demo.py collect.py gate.py run.py report.schema.json verify.py; do
  curl --fail --silent --show-error \
    "https://lizard.build/blog-examples/agent-deployment-checks/$file" \
    --output "$file"
done
python3 demo.py --port 8787

Leave that terminal running. In another terminal, change to the same folder. The demo exposes /healthz and /api/quote?quantity=3. Each item costs 1,200 cents; a quote for three items must return currency: USD and total_cents: 3600.

These are demo routes. For your own application, edit the paths and expected fields in collect.py and gate.py. Choose a small operation a user actually needs: reading a seeded record, calculating a price or fetching a saved document. A route that only returns “OK” cannot verify those operations.

Collect evidence before asking Claude

python3 collect.py http://127.0.0.1:8787 > evidence.json

The collector makes two requests with a five-second timeout for each. It rejects redirects, invalid JSON and responses larger than 64 KiB. It checks both the HTTP status and the expected JSON fields. It records the time, expected values and check results; it does not copy arbitrary response text into the prompt.

That last choice matters when an endpoint contains user text. A support message or database row can contain instructions aimed at an agent. This example gives Claude a small set of measured fields to explain.

The collector exits successfully when it writes evidence, including evidence of a failed check. The final check script determines whether the job passes. Keep those two meanings separate in your automation.

Ask for a structured report

Run this from the folder containing the downloaded files:

claude --safe-mode -p \
  "Explain the evidence on stdin. Use no tools. Copy its verdict. List the names of failed checks in failed_checks. Give a short summary and one next_step. Do not infer a root cause from HTTP status alone." \
  --tools "" \
  --no-session-persistence \
  --output-format json \
  --json-schema "$(cat report.schema.json)" \
  < evidence.json > claude-result.json

The example uses --safe-mode to disable customizations such as hooks, plugins and MCP servers during this report task. It uses the existing account login. Check your installed version's help if it does not recognize the flag.

Claude's response has an outer result object. When you supply the schema, the report sits inside structured_output. The outer object also carries run metadata and an is_error field. A plain JSON response and a schema-constrained response serve different purposes; parse the field your command requested.

The schema asks for four fields:

Field	Purpose
`verdict`	`pass` or `fail`, copied from the checks
`failed_checks`	Names of the checks that failed
`summary`	A short explanation of the observed result
`next_step`	One concrete follow-up

The programmatic execution documentation describes these output formats. A valid JSON shape does not establish whether the explanation is correct, so the wrapper checks the report against the measured results.

Run the complete check

run.py collects fresh evidence, calls Claude with a 180-second process timeout, extracts the report and checks it. Give each run a new output directory:

python3 run.py claude http://127.0.0.1:8787 runs/healthy

The directory contains evidence.json, claude-result.json, report.json and stderr.log. Keep the raw result when debugging a failure; an authentication error can appear in the result on stdout.

The wrapper uses three exit codes:

Exit code	Meaning
`0`	Both application checks passed and the report agreed
`1`	At least one application check failed and the report agreed
`2`	The reporting job failed, timed out or returned invalid or contradictory output

Code 0 from the Claude process means the agent run completed. The wrapper makes the separate decision about the application. An invalid report cannot turn a failed HTTP check into a successful job.

Reproduce a failure that a health check misses

Start a second demo in another terminal:

python3 demo.py --port 8788 --broken

Then run:

python3 run.py claude http://127.0.0.1:8788 runs/broken

The second demo still answers /healthz with HTTP 200. Its quote route returns HTTP 503. The evidence therefore records fail, with quote as the failed check. With a valid Claude response, the wrapper exits 1.

You can also test the HTTP checks and validation logic without calling a model:

python3 verify.py

This checks the healthy and broken demos, then verifies that the gate rejects a false success report and incomplete evidence. It does not use Claude credits.

Apply the check to an application on Lizard

Choose the application URL from your project. Inspect the current project context and service state with Lizard CLI:

lizard skills get core --json
lizard status --json
lizard ps --project YOUR_PROJECT --json
lizard logs --project YOUR_PROJECT --service YOUR_SERVICE --tail 100 --json

lizard status shows the local folder's link. lizard ps reads the service state for the selected project. JSON logs return a bounded snapshot and exit; they do not keep following the service.

Use the service's public URL with the same checker after you adapt the two route assertions to your application. If you host the supplied demo itself, bind it to 0.0.0.0 and configure the service's port to match. The local examples bind to 127.0.0.1.

Read logs around the recorded check time when a route fails. An HTTP 503 alone cannot tell you whether the cause was a database connection, a dependency or application code. Review and redact any logs before adding them to a model prompt.

For applications that depend on stored data, add a test with a known record. The Postgres MCP guide explains scoped database access, and the Redis MCP guide covers restricted Redis reads. Use test data and credentials suited to the check.

Headless mode, authentication and unattended jobs

Headless mode describes how you run the command. It does not create an unattended login or remove tool permissions. For a scheduled job, prepare authentication on the runner and use an explicit timeout.

Claude also offers --bare, which skips much of the normal startup context. Its Anthropic authentication path uses ANTHROPIC_API_KEY or a configured API key helper; it does not read subscription OAuth credentials. Our account-login example therefore uses --safe-mode. Review the current documentation before moving the job to CI, where the authentication setup may differ.

For live progress, Claude supports --output-format stream-json --verbose. Each line is an event. Use plain json when you only need one final result, as this example does. Avoid resuming an old conversation for an independent deployment check; each run should use fresh observations.

Troubleshooting

Symptom	Check next
OAuth session expired	Run `claude auth login`, then retry the actual request
The report file contains an error	Inspect the Claude exit code and outer `is_error` field
`structured_output` is missing	Confirm both schema and JSON output flags reached the CLI
A tool waits for approval	Decide which operation the job needs; this report task disables built-in tools
`/healthz` passes but the wrapper exits 1	Inspect the quote check and logs at the recorded time
The wrapper exits 2	Inspect stderr, raw result and schema; use a new output directory on retry
A hosted route redirects to a login page	Use the correct test endpoint and its intended authentication; the demo checker rejects redirects

Test scope and next step

On September 28, 2026, we ran the local HTTP and report-validation tests with Python 3.12.10. They covered healthy responses, a broken quote route, a false success report and missing evidence. We checked the command flags against Claude Code 2.1.259, Lizard CLI 4.0.8 and the official documentation. The Claude model response was not part of the completed tests; the report behavior above describes the documented output contract. These synthetic tests do not establish the health of a production application.

For the same pattern with JSONL events and a separate final report file, see Codex Exec deployment checks. To put your own app online, follow the Claude Code deployment guide, then add a check for the operation your users need most.

Redis MCP: Connect Your AI Agent to Your Database

Yura Oak — Sat, 26 Sep 2026 20:39:40 +0000

Redis MCP lets an AI client call tools that read and change data in your Redis database. To connect your own database, run the official redis-mcp-server, give it a Redis address and a restricted credential, then register that process in Cursor or Claude Desktop.

This guide gets that connection working with two small demo keys. You will read a string and a hash, inspect a TTL, and check that Redis rejects a write. You can start on your computer, then use the same approach with a dedicated Managed Redis instance in Lizard (lizard.build).

Tested September 27, 2026, Dubai time: Python 3.12.10, Redis 8.8.0, redis-mcp-server 0.5.1, MCP Python SDK 1.30.0 and redis-py 8.1.0. The downloadable test passed 14 checks against an isolated local Redis process through MCP over stdio. It did not test a hosted database, TLS or the Cursor and Claude Desktop interfaces. Those setup steps follow the linked product documentation. This guide was prepared with AI assistance; the test script and results are available below.

Choose the Redis MCP server that accesses data

The official Redis MCP server connects to a Redis endpoint. Its tools include string and hash reads, writes, key inspection and server information. Redis enforces the permissions of the credential you supply.

There are several Redis tools with MCP in their names:

Tool	What it connects to	Use it for
`redis/mcp-redis`, packaged as `redis-mcp-server`	Your Redis database	Reading or changing application data
Redis documentation MCP at `redis.io/mcp`	Redis documentation	Looking up commands and examples
Redis Cloud MCP	The Redis Cloud management API	Managing Redis Cloud resources

We use the first one. A documentation connection will not give your agent access to your keys. Redis describes the distinction in its agent setup guide.

The MCP process runs on the same computer as your client and communicates through standard input and output, or stdio. It opens a separate network connection to Redis. This setup needs no public HTTP endpoint for MCP. A green connection indicator in the client only shows that the MCP process started; a tool call must still prove that Redis authentication and data access work.

1. Prepare a small Redis database

Use a dedicated learning instance with synthetic data. You need Python 3.10 or later, uv, and access to a Redis server. The local route also needs redis-server on your PATH.

Download these files into a new demo directory:

requirements.txt: the pinned Python packages.
setup.py: creates two keys and a restricted reader, then writes the MCP configuration.
verify.py: starts its own local Redis process and tests the MCP connection.
validation.json: the results from this guide's test run.

On macOS or Linux, create the Python environment:

uv venv .venv --python 3.12
uv pip install --python .venv/bin/python -r requirements.txt

In a separate terminal, start a temporary Redis instance:

redis-server --bind 127.0.0.1 --port 6391 --save "" --appendonly no

Leave that terminal running. This local instance has no persistence and listens only on loopback. Stop it with Ctrl+C when you finish. If port 6391 already belongs to another process, pick a free port and set ADMIN_REDIS_URL to match before running setup.

In your demo directory, run:

.venv/bin/python setup.py

The setup script connects to redis://127.0.0.1:6391/0 by default. It creates:

Key	Type	Value	Initial TTL
`mcpdemo:status`	String	`ready`	3,600 seconds
`mcpdemo:session:42`	Hash	`user=demo-user`, `language=english`	3,600 seconds

It also creates the user mcp_reader with a random password. It refuses to replace an existing user or demo keys, so a repeat run on the same instance stops with an explanation.

The script saves mcp.local.json with an absolute path to the installed MCP server. The file contains the reader password. Keep it private and add these paths to the demo project's .gitignore before committing anything:

.venv/
.env
mcp.local.json
.cursor/mcp.json
test-runs/

On Windows, use .venv\Scripts\python.exe for the Python commands. The script chooses the matching executable path for the generated config. This guide's automated run used macOS.

2. Understand the reader's permissions

The script applies this Redis ACL policy. This is Redis command syntax, with a placeholder password; the setup script generates the real password for you:

ACL SETUSER mcp_reader reset on >REPLACE_WITH_RANDOM_PASSWORD ~mcpdemo:* -@all +ping +get +hget +hgetall +type +ttl

The rules permit reads of known strings and hashes under mcpdemo:*, plus type and TTL checks. They deny writes, administration commands, pub/sub and key enumeration. The Redis ACL reference explains each rule.

A read-only prompt does not enforce read-only access. The database credential does. The MCP server can still advertise write tools; Redis should reject their execution for this user. Keep the client's approval prompts enabled as another check on which calls run.

Why the policy does not allow SCAN

An ACL key pattern restricts access to key values. It does not make SCAN return only the key names under that pattern. In our test, granting +scan let mcp_reader discover the name private:sentinel, even though it could not read that key's value. Revoking SCAN blocked enumeration again.

Start with known demo keys. If you later allow browsing on a separate instance that holds no unrelated data, use scan_keys in small iterations and follow the returned cursor until it becomes zero. COUNT is a work hint, not a hard result limit. See the SCAN reference. The tutorial's default policy deliberately rejects both scan_keys and scan_all_keys.

3. Add Redis MCP to Cursor or Claude Desktop

Open the generated mcp.local.json locally. It has this shape:

{
  "mcpServers": {
    "redis-demo": {
      "command": "/ABSOLUTE/PATH/redis-mcp-demo/.venv/bin/redis-mcp-server",
      "args": ["--host", "127.0.0.1", "--port", "6391", "--db", "0"],
      "env": {
        "REDIS_USERNAME": "mcp_reader",
        "REDIS_PWD": "YOUR_GENERATED_READER_PASSWORD"
      }
    }
  }
}

Use the actual generated file, not the placeholders above. Merge the redis-demo entry into your client's existing mcpServers object; keep any other servers already there.

Cursor: use .cursor/mcp.json in the demo project, or ~/.cursor/mcp.json for a user-level setup. Check the server in the client's MCP settings and enable it for the project. Cursor documents the file locations in its MCP integration guide.

Claude Desktop: merge the entry into claude_desktop_config.json. On macOS that file lives under ~/Library/Application Support/Claude/. Restart the app after saving. Follow the Redis client configuration guide for the current client steps.

This guide passes host, port and database as explicit arguments. In the tested 0.5.1 command-line entry point, default CLI values overwrite those settings if you supply only environment variables. Supplying REDIS_HOST alone can therefore leave the process trying 127.0.0.1. The username and password in the configuration above use the supported REDIS_USERNAME and REDIS_PWD variables.

4. Prove that the connection works

Ask your client to use the Redis tools explicitly. Approve the requested reads and inspect the tool output before relying on the model's summary.

Use redis-demo to get mcpdemo:status. Then use hgetall on
mcpdemo:session:42 and type on that same key. Report the raw
tool results and the remaining TTL. Do not change any data.

The expected results are:

get returns ready.
hgetall returns the two synthetic fields.
type returns hash and a positive TTL below 3,600 seconds.

The official type tool includes TTL in its response. In our run it returned:

{
  "key": "mcpdemo:session:42",
  "type": "hash",
  "ttl": 3591
}

Your number will differ. A TTL of -2 means the key does not exist; -1 means it exists without expiry. If more than an hour has passed, the demo data may have expired. An authorised administrator can reseed the keys, or you can start a fresh local instance and run setup again.

Next, use the disposable demo to check the restriction:

Use redis-demo to try setting mcpdemo:status to changed once.
Report the exact tool result. Then read mcpdemo:status again.
Do not retry with other tools or credentials.

Our MCP call returned User mcp_reader has no permissions to run the 'set' command, and a separate read still returned ready. This verifies both the denial and the unchanged value. Some Redis MCP tools return an error as text, so inspect the response content even when the MCP call itself completes.

You can reproduce the underlying protocol checks without a model API key:

.venv/bin/python verify.py

The script starts its own Redis process on a free loopback port. It does not accept your database URL. It checks authentication, MCP startup, advertised tools, reads, TTL, blocked writes, unchanged data, another key prefix, missing keys, and the SCAN behaviour above. It stops only the process it created and saves validation.json beside the script.

5. Connect a dedicated Managed Redis instance

For a shared application database, create Managed Redis in the project dashboard and follow the connection guide. Use a separate learning instance for this exercise. Copy its connection URL into a private local .env file under the name ADMIN_REDIS_URL; never paste that administrator credential into an AI chat.

Load your own trusted file and run setup from the demo directory:

set -a
. ./.env
set +a
.venv/bin/python setup.py
unset ADMIN_REDIS_URL

The setup script uses that credential to create the synthetic keys and reader. Its generated MCP configuration contains only the new reader credential. It extracts host, port and database from the URL, and enables TLS certificate verification for rediss:// endpoints. Query parameters and custom certificate paths need a separate configuration; the script stops rather than guessing them.

The endpoint must be reachable from the computer running MCP. A plain redis:// URL has no transport encryption. Use a trusted private route or a verified TLS endpoint where available; changing the URL prefix does not add TLS support to a server. The current Managed Redis guide shows redis:// connections, so do not assume it supplies a public TLS endpoint.

Creating an ACL user also requires the provider to permit ACL SETUSER. If the provider denies it, use its supported user-management controls before connecting the agent. Do not put the administrator password into the MCP config as a workaround.

Redis ACL changes made at runtime need a persistence mechanism to survive a Redis restart. The current Managed Redis startup configuration does not declare an ACL file, so treat this demo user as temporary and verify it after restarts. Do not assume AOF persistence saves ACL users. Keep the tested permissions in your setup process and review the storage and recovery guide for the service's other limits.

Fix common Redis MCP connection errors

Symptom	Check
MCP process fails to start	Use the absolute executable path from the generated config. Confirm that the Python environment still exists.
Connection refused or timeout	Check the explicit `--host` and `--port`, Redis availability and network access from the MCP computer.
`WRONGPASS` or authentication failed	Check `REDIS_USERNAME` and `REDIS_PWD`. A password for `default` does not authenticate `mcp_reader`. Check whether a restart removed the temporary ACL user.
`NOPERM` or a permission error	Compare the requested command and key with the ACL. A denied write, `SCAN` or unrelated prefix is expected in this guide.
`WRONGTYPE`	Use `type` first. Read strings with `get`; read hashes with `hgetall`.
Missing key or TTL `-2`	Check the database number, exact key name and expiry.
TLS certificate failure	Confirm the server actually supports TLS and supply its trusted CA through the server's documented SSL options. Keep certificate checks enabled.
`JSON.GET` or `FT.SEARCH` is unknown	Those tools need the matching Redis JSON or search capabilities. Core string/hash tools working does not prove those capabilities exist.

What to build after the connection works

Use this setup to inspect a synthetic session, check a cache entry's lifetime or debug an agent's saved context. Tool results can enter your model conversation, so choose which data the agent may read before you connect a real application.

If you want the application to save memories automatically, continue with AI agent memory with Redis. If your agent needs relational data, use the separate reader role in Postgres MCP.

Start with Managed Redis, connect the restricted reader, and verify one successful read and one denied write before expanding the tool set.

AI Agent Memory with Redis: Remember Users Across Sessions

Yura Oak — Fri, 25 Sep 2026 14:57:30 +0000

AI agent memory with Redis lets your application save context between model calls and load it when the same user returns. The model sees that context in its next request. Redis holds the data; your application decides what to keep, retrieve and forget.

In this guide, a small Python assistant remembers that Alice prefers vegetarian meals. We stop one Python process, start another with a new session ID, and ask it to recall her preference. Bob gets a separate profile. A forget command removes Alice's live Redis records.

You can run the example locally, then connect the same code to Managed Redis in Lizard (lizard.build). It uses standard Redis Hash and List commands, so this walkthrough needs no vector index, RedisJSON or agent framework.

Tested on September 25, 2026: Python 3.12.10, Redis 8.8.0, redis-py==5.2.1 and four live calls to openai/gpt-4.1-mini through OpenRouter. All 16 checks passed. The test covered separate application processes and sessions on a local Redis instance. It did not cover a hosted instance, concurrent requests or recovery from a Redis crash.

What should an AI agent remember?

Start with two kinds of data. They need different keys and retention rules.

Memory	What it contains	Redis type	Retention in this example
User profile	A preference the user explicitly saves	Hash	30 days after the last profile write
Session history	Recent user messages and assistant replies	List	Latest 20 messages; expires 24 hours after the last completed turn

The profile belongs to the user, so a new session can read it. Conversation history belongs to one user and one session. Starting a second session does not copy the first session's transcript.

This distinction matters when the agent answers “What do you know about me?” A recent message can disappear from a bounded history list. A saved preference has its own retention period. Neither has to stay in the model's context forever.

Redis also offers a separate Redis Agent Memory service. This tutorial builds a small memory layer in application code using a Redis connection. It does not use that service or its automatic extraction features.

1. Set up the demo

You need Python 3.10 or later, a disposable Redis instance and an OpenRouter API key. Use invented preferences while testing: the saved profile and selected chat messages go to the model provider on each call.

Download the complete, tested program and install its one Python dependency:

mkdir redis-memory-demo
cd redis-memory-demo
python3 -m venv .venv
. .venv/bin/activate
python -m pip install redis==5.2.1
curl -fsSLo memory_agent.py \
  https://lizard.build/blog-examples/redis-agent-memory/memory_agent.py

For a local test, run Redis in a separate terminal. This command binds it to loopback on port 6387; keep that terminal running:

redis-server --bind 127.0.0.1 --port 6387 --save "" --appendonly no

This local Redis process is deliberately disposable. Its data remains available when the Python application exits, but stopping Redis loses that data. The test below restarts the application, not the database.

Create a private .env file in the demo directory using your editor:

REDIS_URL=redis://127.0.0.1:6387/0
OPENROUTER_API_KEY=replace-with-your-key
OPENROUTER_MODEL=openai/gpt-4.1-mini

Keep .env out of Git. Restrict access and load it into the current shell:

chmod 600 .env
set -a
. ./.env
set +a

The example calls the OpenRouter Chat Completions API. Redis handles the same memory reads and writes if you replace the model call with another provider.

2. Give each user and session their own keys

The program creates keys like these:

agentmem:v1:{alice}:profile
agentmem:v1:{alice}:session:session-1
agentmem:v1:{alice}:session:session-2
agentmem:v1:{bob}:profile

The version prefix gives future data formats a separate namespace. The user ID separates profiles. The session ID separates conversations. The braces are a Redis hash tag; they keep one user's keys in the same hash slot if you later use Redis Cluster. This guide tests a single Redis instance.

The demo validates IDs before building keys. In a web application, derive the user ID from the authenticated server session. Do not accept another user's ID from a request body and treat it as proof of identity. Redis key names alone do not enforce who can access a user's data.

3. Save an explicit preference

Save Alice's choice:

python memory_agent.py remember --user alice --preference vegetarian

The command prints Preference saved. Internally, it writes a field to a Redis Hash and sets the profile's expiry in a transaction:

with client.pipeline(transaction=True) as tx:
    tx.hset(profile, mapping={"dietary_preference": preference})
    tx.expire(profile, 30 * 24 * 60 * 60)
    tx.execute()

The only allowed values are vegetarian, vegan and no_preference. That small schema makes the example easy to inspect. The model cannot write arbitrary claims into the profile. In a real product, a “Remember this” control can make the same validated write after the user confirms it.

This guide does not infer preferences from every chat message. Changing or correcting a preference uses the same explicit command, which overwrites that field and renews its 30-day TTL.

4. Load memory before calling the model

Ask the assistant to recall the saved choice:

python memory_agent.py chat --user alice --session session-1 \
  --message "What dietary preference have I saved?"

In our test, the model replied:

Your saved dietary preference is vegetarian.

For each call, the application reads the user's profile and the current session's recent messages. It builds the model request in this order:

Instructions that define the assistant's task.
A data message containing the allowed saved preference.
This session's recent user and assistant messages.
The new user question.

The model has no direct Redis credentials or general database tool. It only receives the selected context. After a successful reply, the app stores the new user and assistant messages together:

with client.pipeline(transaction=True) as tx:
    tx.rpush(history, *rows)
    tx.ltrim(history, -20, -1)
    tx.expire(history, 24 * 60 * 60)
    tx.execute()

Each turn contributes two messages, so the list keeps the last ten complete turns. The app also caps each message at 2,000 characters. A message count alone would not bound context size if one message could contain an entire book.

In this example, reading memory does not renew its expiry. Profile writes renew the profile TTL; completed chat turns renew the session TTL. See the Redis EXPIRE reference for how expiry interacts with updates.

5. Start a new process and a new session

Each CLI command starts and exits its own Python process. Run a second chat command with a different session ID:

python memory_agent.py chat --user alice --session session-2 \
  --message "What dietary preference have I saved?"

The model again returned Your saved dietary preference is vegetarian. The new session began without the first conversation's messages. Its request contained the shared user profile, which was enough to answer.

Inspect the records the application reads:

python memory_agent.py inspect --user alice --session session-2

You should see a profile with dietary_preference and a history with that session's user question and assistant answer. The model has not learned a new weight or gained permanent internal memory. The application supplies the stored context on each request.

6. Check user separation and forgetting

First, inspect another user's context:

python memory_agent.py inspect --user bob --session session-1

For a fresh Bob profile, the result is:

{
  "profile": {},
  "history": []
}

Asking Bob's assistant the same preference question produced Your dietary preference is unknown. in our test. The empty context is the deterministic isolation check; model wording can vary.

Next, stop any requests for Alice and remove her live Redis memory:

python memory_agent.py forget-user --user alice
python memory_agent.py inspect --user alice --session session-1
python memory_agent.py inspect --user alice --session session-2

Both inspections should return empty profiles and histories. The command scans only Alice's validated key prefix and unlinks matching keys. It leaves Bob's keys alone.

For a deployed app, block new writes for that user while deletion runs. Otherwise, a reply that finishes during the scan could recreate a session. Deleting Redis keys also does not delete provider logs, backups or records in another database; those stores need their own retention and deletion rules.

What we tested

The verification script starts a new Redis process on an available loopback port. It never connects to an existing database. Its saved results record the versions, scope and four model replies.

Check	Result
A saved preference survives separate Python processes	Passed
A new session loads the profile without the old transcript	Passed
Another user starts with an empty context	Passed
Expired profile and session keys disappear	Passed
History stays within 20 messages and preserves complete turns	Passed
Forgetting removes both sessions and the profile, leaving another user intact	Passed
Live model calls recall the preference before deletion and report it unknown afterward	Passed

The harness ran 16 checks in total. These results show that the example's reads and writes work as described. They do not establish a production availability or data recovery guarantee.

Connect the example to Managed Redis

After the local test, create a separate Redis instance for your project. In a linked Lizard project, run:

lizard add redis

For a deployed service named api, set the connection reference and redeploy:

lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service api
lizard redeploy --service api

These commands assume the service already exists and has its model API key configured. They connect that service to Redis; the CLI demo itself is not an HTTP server. Follow the Managed Redis connection guide for environment variables and access from your computer.

You can inspect the demo's keys in the Redis browser in the dashboard. Keep Redis credentials on the server, and use a private connection or verified TLS when your provider supplies it. A plain redis:// URL does not add transport encryption.

Decide which memories must survive data loss

Memory surviving an application restart does not mean it survives every Redis failure. Expiry, key eviction, persistence settings and backups all matter.

Managed Redis currently documents an allkeys-lru eviction policy: memory pressure can remove any key, including a profile whose TTL has not elapsed. For preferences you cannot afford to lose, keep the source record in Managed Postgres and use Redis for recent context or a reloadable copy. Review the storage and recovery guide before choosing a retention policy.

Before you put this behind a web API

The CLI keeps the example small. A shared application also needs:

Authentication and ownership checks. Derive user IDs on the server and check that each session belongs to that user.
One active turn per session. Queue or lock the full read → model call → write sequence. The final Redis transaction alone does not stop two model calls from reading the same old context.
A memory size budget. Bound profile fields, message size, history length and the number of sessions. Monitor Redis memory and evictions.
A Redis failure policy. Fail the request clearly or offer an explicitly stateless mode. Never claim a preference was saved when the write failed.
Separate authority from remembered text. A saved message can contain hostile instructions. Keep permissions and tool decisions in application code; a system prompt is not an access-control boundary.

Common questions

Do I need a vector database for AI agent memory?

You can load a known user's explicit preferences and recent messages by key, as this example does. Vector search becomes useful when the application must find relevant facts in a much larger set of memories. That adds embeddings, index configuration and retrieval tests.

Does Redis make an agent remember forever?

Retention depends on TTLs, eviction, persistence and your application's writes. This example deliberately expires data. Keep durable records elsewhere when losing them would break the product.

Is this RAG or a semantic cache?

This example retrieves one user's saved context. RAG commonly retrieves relevant source material to help answer a question. A semantic cache reuses a prior answer for a similar query. They can share Redis infrastructure, but they need different data models and tests.

Can I use LangGraph later?

Yes. LangGraph offers checkpoints for conversation state and stores for memory across threads. Its Redis integration has its own requirements; check the LangGraph Redis package documentation before replacing this simple client with a framework backend.

Give your agent a memory you can inspect

Start with one explicit fact, a separate session history and a test that crosses a process boundary. Add expiry, ownership checks and a way to forget before you add automatic extraction or vector search.

Create Managed Redis for the application's shared context. If your agent also needs to query structured project data, the Postgres MCP guide covers that connection with a separate database reader role.

Postgres MCP: connect your AI agent to a database

Yura Oak — Fri, 25 Sep 2026 11:40:38 +0000

A Postgres MCP server lets an AI agent inspect a PostgreSQL schema and run queries through the Model Context Protocol. You give the server a database connection; your agent calls its tools to read tables and answer questions about the data.

This guide connects Cursor to a sample database using Postgres MCP Pro, a separate database role and restricted access mode. The end result is easy to check: the agent should find two active projects with a combined monthly budget of $68. It should fail if it tries to change those rows.

You can create the database with Managed Postgres on Lizard (lizard.build). The MCP process runs on your computer. The same SQL setup also works with a local PostgreSQL instance you own.

How Postgres MCP connects to your database

The agent sends a tool call to the MCP server. The server connects to PostgreSQL, runs the query and returns the result. PostgreSQL checks the permissions of the connection's database role.

We use Postgres MCP Pro, an independent open-source project. It exposes tools for listing schemas, reading table details and executing SQL. Lizard supplies the database in this setup.

The local connection between Cursor and the MCP process uses stdio. Your computer must be able to reach the database endpoint. Query results can enter your AI provider's context, so this walkthrough uses invented project names and budgets.

What you need

A new PostgreSQL instance or a separate disposable database, with an owner account that can create a database and a role.
psql on your computer.
uv, which runs the pinned Python package.
Cursor with custom MCP servers enabled.

We tested the SQL and MCP calls with PostgreSQL 14.20, Python 3.12.10, postgres-mcp==0.3.0 and mcp==1.30.0. The result table below records the scope of those checks.

1. Create a sample Postgres database

In a new Lizard project, add Managed Postgres from the dashboard. If you already use Lizard CLI and have linked the new project, run:

lizard add postgres

The dashboard provides the host, port, database and credentials. Follow the Managed Postgres connection guide to connect with psql. Use the owner account for this setup; the agent will receive a different account.

In psql, create and switch to a fresh database:

CREATE DATABASE mcp_demo;
\connect mcp_demo

\connect is a psql command. If you use a SQL editor, select mcp_demo before running the next block. If the database name already exists, choose another name and update the later examples.

Create one table with three rows:

CREATE SCHEMA demo;

CREATE TABLE demo.projects (
  id integer PRIMARY KEY,
  name text NOT NULL,
  status text NOT NULL CHECK (status IN ('active', 'paused')),
  monthly_budget_usd numeric(10, 2) NOT NULL
);

INSERT INTO demo.projects VALUES
  (1, 'Atlas', 'active', 49.00),
  (2, 'Beacon', 'active', 19.00),
  (3, 'Cedar', 'paused', 0.00);

These amounts belong to the sample data. They are not Lizard prices.

2. Give the agent a role that can read the sample table

Create a login with no administrative privileges:

CREATE ROLE mcp_reader LOGIN
  NOSUPERUSER NOCREATEDB NOCREATEROLE NOREPLICATION NOINHERIT;

Then run this psql command to set its password without putting the password in SQL history:

\password mcp_reader

The following grants are for the fresh mcp_demo database. The PUBLIC revocations affect other roles that use that database, so do not paste this block into an existing shared application database.

REVOKE ALL ON DATABASE mcp_demo FROM PUBLIC;
REVOKE CREATE ON SCHEMA public FROM PUBLIC;

GRANT CONNECT ON DATABASE mcp_demo TO mcp_reader;
GRANT USAGE ON SCHEMA demo TO mcp_reader;
GRANT SELECT ON demo.projects TO mcp_reader;

ALTER ROLE mcp_reader IN DATABASE mcp_demo
  SET default_transaction_read_only = on;
ALTER ROLE mcp_reader IN DATABASE mcp_demo
  SET statement_timeout = '5s';

This grants access to one table. A table you create later needs its own grant. PostgreSQL may still expose object names through system catalogs; table permissions control access to the rows. See PostgreSQL's GRANT reference.

The read-only default helps avoid mistakes, but a client can change that setting. The table grants are what prevent this role from writing to demo.projects. We checked that an update still fails after turning the default off.

3. Save the reader connection outside your source code

Build a connection URL using the new role and the mcp_demo database. Keep the host, port and required TLS settings from your provider's connection instructions. Percent-encode special characters in the password when putting it in a URL; PostgreSQL documents the connection URI format.

For a hosted endpoint that requires TLS, the shape is:

postgresql://mcp_reader:URL_ENCODED_PASSWORD@DB_HOST:DB_PORT/mcp_demo?sslmode=require

sslmode=require requires encryption. If your provider supplies a CA certificate and hostname for full certificate checks, use its verify-full configuration. A certificate error needs a matching host and trust configuration; do not solve it by disabling TLS on a hosted connection.

Add .env.mcp to your project's .gitignore, then create that file at the project root:

DATABASE_URI=postgresql://mcp_reader:URL_ENCODED_PASSWORD@DB_HOST:DB_PORT/mcp_demo?sslmode=require

Replace every placeholder with your reader connection values. The name is DATABASE_URI: that is what Postgres MCP Pro expects. Lizard's application connection variable is named DATABASE_URL; passing that name alone will not configure this MCP server.

Keep the owner connection out of this file. On macOS or Linux, restrict access to the reader file:

chmod 600 .env.mcp

4. Configure Postgres MCP in Cursor

Create .cursor/mcp.json in the same project. If the file already contains other servers, add postgres-demo inside its existing mcpServers object.

{
  "mcpServers": {
    "postgres-demo": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "--python", "3.12",
        "--with", "mcp==1.30.0",
        "--from", "postgres-mcp==0.3.0",
        "postgres-mcp", "--access-mode=restricted"
      ],
      "envFile": "${workspaceFolder}/.env.mcp"
    }
  }
}

Cursor supports project MCP configuration and envFile for local stdio servers. See its MCP configuration reference. If Cursor cannot find uvx, replace the command with its full installed path.

The two version pins matter. During our check, installing postgres-mcp==0.3.0 without an MCP SDK constraint selected mcp==2.2.0. The server then failed to import mcp.server.fastmcp. With mcp==1.30.0, it started and completed the tests below.

To check the package launch before opening a database connection, run:

uvx --python 3.12 --with 'mcp==1.30.0' \
  --from 'postgres-mcp==0.3.0' postgres-mcp --help

Enable or restart postgres-demo in Cursor's MCP settings. Leave tool approval enabled while checking the setup, and inspect the SQL arguments before allowing a call.

5. Verify the tools and the answer

Start with a schema question:

Use postgres-demo to inspect the demo schema. List its tables and the columns
of demo.projects. Show the tool results. Do not change the database.

The server should expose list_schemas, list_objects, get_object_details and execute_sql. Confirm that the agent calls the tools and reports id, name, status and monthly_budget_usd from the table.

Then ask:

Using demo.projects, how many projects are active and what is their total
monthly budget in USD? Show the SQL and the database result.

A query for that answer is:

SELECT
  count(*) AS active_projects,
  sum(monthly_budget_usd) AS total_budget_usd
FROM demo.projects
WHERE status = 'active';

The expected values are:

active_projects	total_budget_usd
2	68.00

Finally, check the restriction on this sample table. The WHERE false condition ensures the query has no matching rows:

Use execute_sql to run exactly:
UPDATE demo.projects SET name = name WHERE false;
Report the tool response. Do not retry with another tool or connection.

In our test, restricted mode returned Error: Error validating query. A separate direct connection using mcp_reader returned permission denied for table projects even after we disabled its read-only default. The MCP check and database grants each rejected the operation.

What we tested

On 24 September 2026, we ran the sample SQL and real MCP calls against a new local PostgreSQL 14.20 instance with synthetic data. We used Python 3.12.10, Postgres MCP Pro 0.3.0 and MCP SDK 1.30.0.

Check	Result
Connect as `mcp_reader`	Connected to `mcp_demo`; read-only default on
List the schema, table and columns through MCP	Returned the sample schema and table fields
Query the active projects directly and through MCP	Both returned 2 projects and $68.00
Try an update through restricted MCP mode	Rejected during query validation
Try an update directly with the read-only default off	Rejected by PostgreSQL table permissions
Read a table in an ungranted test schema	Rejected by PostgreSQL schema permissions
Check table creation in the public schema and temporary table privileges	Neither granted

These checks cover the SQL permissions and MCP protocol. We did not run the Cursor UI flow or deploy a new Lizard database for this test. Follow the checks above against your own endpoint; a connected MCP indicator alone does not prove the database tools work.

Fix common Postgres MCP connection errors

Symptom	What to check
`No module named mcp.server.fastmcp`	Use the tested `mcp==1.30.0` pin with Postgres MCP Pro 0.3.0. Restart the server after changing its arguments.
`uvx` not found	Install uv, then use the full path to `uvx` in Cursor if needed.
Missing database URL	Confirm `.env.mcp` contains `DATABASE_URI` and that `envFile` points to the right project.
Password authentication failed	Use the password for `mcp_reader`, check URL encoding and confirm the endpoint.
Connection timed out or refused	Check host, port, network access and whether the database is running. A private service hostname may not resolve from your laptop.
Certificate verification failed	Match the provider's hostname, CA certificate and TLS settings.
Permission denied for schema or table	Check `USAGE` on the intended schema and `SELECT` on the intended table. Grant only the access the example needs.
Empty table list	Confirm the database name and schema. This guide puts the table in `demo`, not `public`.

Do you need PostgreSQL extensions?

The schema and data queries in this guide need no extra extension. Postgres MCP Pro also offers performance tools that have different requirements.

Its top-query analysis uses pg_stat_statements. Hypothetical index analysis uses hypopg. Availability, server configuration and role permissions all matter; creating an extension may require an owner action or a server change. Check the project's extension requirements before using those tools.

Start with the schema and SELECT checks. An extension-related failure in a tuning tool does not, by itself, mean the basic MCP connection is broken.

FAQ

Is Postgres MCP the same as Lizard MCP?

No. This example uses Postgres MCP Pro to query a PostgreSQL database. Managed Postgres provides that database. The connector is a separate project.

Can I use a different AI agent?

Yes, if its client supports local MCP servers over stdio. Use the same pinned process, reader credentials and restricted mode, then follow that client's configuration format. The JSON above is for Cursor.

Does restricted mode replace database permissions?

Use both. Restricted mode checks queries in the MCP server. PostgreSQL's grants limit what the connection role can do even through another client. Keep the owner account for migrations and administration.

Will it create tables or run migrations for me?

This setup grants the reader access to the sample table. It cannot create or change your application's schema. Run reviewed migrations with your normal application deployment process.

Connect the database to your app next

Once the agent can inspect the sample schema and return the expected answer, you have a working basis for database questions during development. Keep the agent's reader credentials separate from your application's credentials as you add tables.

Create Managed Postgres for your project, follow the database connection guide, or continue with the Cursor app deployment example. For deploying an MCP service shared by several clients, see the separate remote MCP server guide.

Originally published on Lizard.

Welcome to the Lizard blog

Yura Oak — Wed, 23 Sep 2026 12:06:30 +0000

The Lizard (lizard.build) blog helps developers turn working code into an application they can deploy, check and operate. It covers the decisions that come after the first successful local run: where the process lives, how it reaches its database, what happens to files and how to recover when something fails.

Start with the task you have

If an agent helped write your app, use the Claude Code deployment guide or Google Antigravity guide. Both explain how to check the live application after deployment.

For Python projects, start with hosting Django, Flask and FastAPI. If you prefer to manage a server, the Django VPS walkthrough covers the process, proxy and release setup.

If you are choosing infrastructure, compare PaaS providers, learn what container as a service includes, or assess Kubernetes alternatives.

How to read our comparisons

We build Lizard, so these articles include our product and explain where it fits. They should also help you identify when another option suits your requirements better.

Prices need their billing units, plan terms and sources. A calculation should state its assumptions. A test result should explain what ran and how it was measured. A product feature should not become a promise about your application's performance or bill.

Use the linked documentation to check the details that matter to your deployment. If you find a mistake or a changed product term, contact us with the page and the claim. For the current command reference and setup instructions, go to the Lizard documentation.

Originally published at Lizard (lizard.build).

Vercel alternatives: choosing a host for your backend

Yura Oak — Wed, 23 Sep 2026 12:05:49 +0000

The right Vercel alternative depends on what your application runs. Compare Lizard (lizard.build), Railway and Render for services that stay active between requests. Consider Cloud Run for an HTTP service that can scale down when demand falls. Keep Vercel on your shortlist when its frontend workflow and request-driven compute fit your app.

This comparison comes from Lizard. We checked the linked product documentation and billing terms on 9 September 2026. The calculations below are examples with stated inputs, not performance tests or customer savings figures.

Start with the runtime you need

A Dockerfile describes how to package an application. It does not tell you how a hosting service schedules, stops or bills that application.

Vercel now supports container images for Functions. Its Services documentation says Services use Function compute and inherit Function limits. Check the current duration, filesystem and connection limits for the specific feature and plan you intend to use.

For a conventional queue consumer, a process that keeps a connection open, or a scheduler that runs outside HTTP requests, test that lifecycle before moving. A managed queue or workflow can solve the same business problem, but it can also require changes to your code.

Your requirement	Options to evaluate	What to test first
Frontend previews and a request-driven backend	Vercel	Framework behaviour, cache rules and production limits
API plus a separate queue consumer	Lizard, Railway, Render	Worker restarts, retries and database access
An HTTP container with uneven traffic	Cloud Run	Cold starts, concurrency and minimum instances
Direct control of a server	A VPS with a deployment tool	Patching, backups and your response to failures

These are starting points for a trial. None establishes a universal winner. Our PaaS comparison covers the broader choice.

Where Lizard fits

Lizard runs web services and workers, offers Managed Postgres, Managed Redis and Managed Object Storage, and exposes deployment and operations through the Lizard CLI.

That fits a backend with a familiar process model: start the API, run the worker separately, and give each service its own configuration. A coding agent can read structured deployment output, inspect logs and run a specific command inside a service. It still needs to check the result; a successful build alone does not prove that logins, jobs and database writes work.

Provisioning a database and connecting your application are separate steps. Your application must read the connection variable you configure. Keep app data in the database or an attached Persistent Volume, according to the service's needs. A writable container filesystem by itself is not a backup or a promise of durability across deployments.

When Vercel is a better fit

Stay with Vercel when your team depends on its preview workflow, frontend tooling or managed request lifecycle and those features already meet your needs. Replacing a working deployment system has a cost even if another provider advertises a lower CPU rate.

An application with little traffic can also benefit from compute that does not remain active between requests. A running Lizard service can still consume memory while waiting for work. Compare the actual workload and latency requirements, including whether you are willing to accept cold starts.

You can keep the frontend on Vercel and move only the worker or API. In that design, include cross-provider data transfer, authentication and request latency in the test.

Compare bills after fees, credits and allowances

The monthly total depends on more than runtime CPU. Record the plan, billing period, region, seats, database, storage, requests, traffic and builds. Apply each allowance to its own meter and each credit once.

Billing term	Lizard	Vercel Pro
Base plan	No monthly subscription	$20/month with one deploying seat
Included usage credit	$10 trial credit, valid for 31 days; purchased credits do not expire	$20 per team, not per seat
Additional deploying seats	No separate seat charge	$20/month each
Internet transfer	$0.045/GB from the first byte	Current Pro terms include a Flat Rate CDN tier with 1 million CDN requests and 1 TB of data transfer
Hosted builds	Builds are billed	Paid build machines bill by CPU-minute

Sources: Lizard pricing, Vercel Pro terms and Vercel build billing. CDN transfer, origin transfer and Function invocations are distinct Vercel meters. Check the terms your account uses before reusing an older estimate.

Hosted build costs: Lizard and Vercel

Lizard charges for builds. Include those charges when comparing deployment costs.

For a paid Vercel Standard machine with 4 vCPUs, 200 builds at exactly 3 billable minutes each use 2,400 CPU-minutes. At $0.0035 per CPU-minute, that is $8.40 before plan credit and tax, or $0.042 per build. Vercel build rates, checked 15 September 2026.

Vercel credits can cover some or all of this usage, so $8.40 is not necessarily an extra payment on top of the plan. Basic builds are included on eligible Vercel Hobby projects. This is a Vercel build-cost example, not a build-speed comparison or the full monthly bill.

Where no subscription lowers the bill

Lizard charges 200 GB of outgoing traffic at 200 × $0.045 = $9. There is no bundled traffic allowance to subtract. Vercel Pro includes a CDN allowance, so compare that meter separately from Function and origin traffic.

For an illustrative small app running for 720 hours, assume average measured use of 0.01 vCPU and 0.1 GB of memory, plus 10 GB of outgoing traffic. No database, retained storage or paid add-ons are included. At Lizard rates:

Lizard costs less for this small-app example than the $20 Vercel Pro monthly minimum, provided Lizard top-up fees allocated to this usage stay below the $18.47 difference. Three deploying seats raise that Pro minimum to $60. These are paid-plan comparisons before tax and trial credits; Vercel Hobby can cost $0 for an eligible project. We do not assume identical resource consumption across the two runtimes. Vercel Pro terms, checked 15 September 2026.

Purchased credits pay for usage and do not expire. A top-up can exceed this month’s usage because the unused balance stays available; the top-up screen shows its fee and total charge.

This example shows a specific price advantage from having no monthly minimum. For a larger app, compare measured resource use, included CDN traffic and required features on both hosts before estimating savings.

Move one service before moving the whole app

List Vercel-specific dependencies: request handlers, image processing, cache behaviour, scheduled work, storage and environment variables.
Choose an API or worker that can run independently. Give it a production start command and a health endpoint where appropriate.
Deploy a test copy and connect it to a separate test database. Configure credentials through service settings.
Test authentication, retries, timeouts, file handling and restarts with representative traffic.
Measure cost and latency, then plan the database and domain cutover. Keep a rollback path until you have checked writes on the new deployment.

For a GitHub repository, start with the Git deployment guide. For a local project, use the upload deployment guide. The CLI configuration reference explains how to keep deployment settings repeatable.

FAQ

Can Vercel run a Dockerfile? Yes. Vercel documents container-image support for Functions. Check the runtime limits as well as the packaging support before treating it as a replacement for an always-running backend.

Is Railway billed as a flat server tier? No. Railway meters resource consumption and applies the paid plan's subscription fee toward usage. Its billing model differs from buying a fixed instance size. See the Railway pricing documentation.

Can I keep Vercel for the frontend? Yes. A separate API or worker can run elsewhere. Test cross-origin requests, cookie settings, authentication and network costs as part of that split.

Which option is cheapest? For the small app priced above, Lizard’s resource cost is about $1.53 plus payment fees, below Vercel Pro’s $20 monthly minimum. Lizard also has no seat fee. Vercel Hobby may be free for an eligible project, and included CDN traffic can change the result for a larger app.

What should an AI coding agent verify after deployment? The live URL, health checks, logs and a real user flow. For a backend, also check database writes, worker execution and recovery after a restart. The Claude Code deployment guide shows that workflow.

Originally published at Lizard (lizard.build).

Deploy from Claude Code: a practical Lizard workflow

Yura Oak — Wed, 23 Sep 2026 12:04:59 +0000

Claude Code can deploy an application by using a hosting provider's tools in your development environment. With Lizard (lizard.build), the agent can inspect the project, use the Lizard CLI to deploy, configure dependencies and check the live service. The host runs the application after the coding session ends.

The useful result is a working user flow at a live URL, not just a command that exits successfully. This guide checks the Lizard CLI and linked documentation as of 9 September 2026.

Give the agent the right context

Start with a repository that builds and has a production start command. Identify the workspace and project that should own it, whether it needs a database or worker, and whether the deploy creates a test copy or changes an existing service.

Install the CLI and read its version-matched instructions:

npm install -g @lizard-build/cli
lizard skills get core --json
lizard status --json

If authentication is needed, use lizard login and finish the browser sign-in. For the reusable agent instructions, follow the Lizard Skill repository. Claude Code's own overview describes how it works with a codebase and tools.

The agent should inspect existing configuration before adding anything. A runtime version, Dockerfile or start command already in the project is better evidence than a command guessed from the framework name.

A prompt that defines the deployment task

Give the agent a bounded instruction such as:

Deploy this repository to the existing Lizard project my-project as a test service. Read the current Lizard CLI guide and inspect the build and start commands first. Use the GitHub source if the repository has an accessible GitHub remote. Configure the services this app actually needs. Verify the live URL, logs and one real application flow. Report the deployed revision and any check that failed.

Replace the project and environment with the intended target. State explicitly when a production service or domain should change. The agent should not infer a production database migration from a request to publish a test copy.

Choose Git deployment or source upload

Use the repository's GitHub integration when you want later commits to trigger deployments. The GitHub deployment guide covers connection and service setup. Check the tracked branch and root directory for a monorepo.

For a local project without a suitable GitHub remote, source upload is available. After selecting the right workspace, a new example project and service can use:

lizard init --name my-project
lizard add --service api
lizard up --service api

These names are examples. For an existing project, confirm the current link with lizard status --json and select the existing service. Do not create another project or switch a Git-backed service to upload merely to avoid reading its settings.

Lizard performs the hosted build. Depending on the project and service configuration, it can use the repository's Dockerfile or generate one through the supported build path. Read the deployment docs and keep the settings in the configuration reference repeatable.

Connect the database deliberately

Creating Managed Postgres does not prove the application can reach it. The application must read the connection variable you set. For a project with a service named api and its first PostgreSQL add-on named postgres, the reference is:

lizard add postgres
lizard secrets set 'DATABASE_URL=${{postgres.DATABASE_URL}}' --service api

Use the add-on's actual name if it differs. Configure each consumer service, including workers, with the variables it needs. Run migrations as a controlled release step and confirm an application read and write against the intended database. See variable references and Managed Postgres.

For uploads, choose storage that survives the lifecycle your app needs. For a worker, check that it can reach the broker and handle restarts. Avoid treating the successful creation of resources as a completed application setup.

Check the result from the outside

Use structured output for diagnostics:

lizard status --json
lizard logs --service api --json
lizard logs --service api --build --json
lizard metrics --service api --json

Then fetch the live URL and exercise a real flow. For a small API, that might be authentication followed by a write and read. For a frontend, check a route reached directly by URL as well as through client-side navigation.

If deployment fails, use the reported error to choose the next check:

Symptom	First checks
Build fails	Dependency lockfile, runtime version and build command
Process exits	Start command, missing configuration and import errors
Health check fails	Bound interface, port and startup time
Page loads but actions fail	API URL, auth, database and callback settings
Files disappear after a change	Storage location and persistence guarantees

An agent should report an unresolved error rather than declare success from the build log. The Python hosting guide gives examples of start-command problems.

Understand the cost of the workflow

Your coding subscription and hosting bill pay for different parts of the work. Lizard uses pay as you go with no monthly subscription. Its pricing page lists resource rates and payment terms. A test service, database or sandbox can continue consuming resources after the coding session ends.

Set resource limits and review use. Stop or remove temporary resources when they are no longer needed through your normal approval process. Do not assume that closing Claude Code stops an application that has already deployed.

FAQ

Does Claude Code host the app? The deployment target does. Claude Code uses tools to prepare and deploy the code; the hosting provider runs the resulting application.

Can I deploy an existing GitHub repository? Yes, if Lizard can access it. Configure the repository, branch and service through the Git deployment workflow, then verify the deployed revision.

Do databases connect automatically? Provision the database, configure the variable the application reads, and test the connection. Those are separate checks.

Can the same workflow work with another coding agent? An agent that can use the required tools can follow the same deployment checks. Read its own permission and tool setup rather than assuming every environment behaves like Claude Code.

How do I know the deployment is complete? Confirm the live URL, expected revision, healthy process and meaningful application behaviour. A successful build alone is not enough.

Originally published at Lizard (lizard.build).

Firebase alternatives: match the backend you need

Yura Oak — Wed, 23 Sep 2026 12:04:17 +0000

Choose a Firebase alternative by the Firebase services you need to replace. Supabase and Nhost belong on a shortlist for a PostgreSQL-based backend. Appwrite offers an integrated backend product. PocketBase can suit a small self-hosted project. Hosting your own API on Lizard (lizard.build) is another approach, but it does not automatically replace Firebase Authentication, security rules or realtime client behaviour.

This comparison comes from Lizard. We checked the linked documentation on 9 September 2026. Start with architecture and migration effort, then compare the bill.

Firebase is more than a database

An app may use Firestore, Realtime Database, Authentication, Storage, Functions, Hosting and messaging in different combinations. Each has its own API and cost model. Firebase pricing lists those products separately.

Exporting documents solves only part of a migration. The client may depend on realtime listeners, offline behaviour and security rules that the new system expresses differently. Authentication also includes identity providers, account recovery and sessions, not just a users table.

Make a list of SDK calls in your application. Use it to define the replacement contract before picking a vendor.

A shortlist by backend model

Option	Why to evaluate it	What needs review
Supabase	PostgreSQL with an integrated backend workflow	SQL schema, access policies and client API changes
Appwrite	Auth, databases, storage, functions and realtime features	API compatibility and cloud versus self-hosted operation
Convex	A reactive backend approach	Its data and function model compared with your existing code
PocketBase	An embedded SQLite backend in a compact application	Production requirements, upgrades and recovery
Nhost	Database, GraphQL, auth and storage in one backend product	GraphQL model, permissions and deployment requirements
AWS Amplify	An application backend built around AWS services	AWS identity, resources and the resulting bill
Your own API and PostgreSQL	Control over the server-side application	Building auth, authorization and realtime behaviour you need

Read the primary product documentation for Supabase, Appwrite, Convex, Nhost and Amplify before treating a feature label as equivalent behaviour.

When PostgreSQL is the reason to move

A relational database can fit data that benefits from joins, transactions and explicit constraints. It also changes how you model and query documents that were designed for Firestore.

Start with the queries your app must answer. Map collections, nested values and identifiers to a schema, then check reads and writes with real data. Do not assume a mechanical conversion of every document produces a useful relational model.

If you choose your own API, Managed Postgres provides the database on Lizard. Your application still implements its endpoints and access checks. Supabase or Nhost may be a closer fit when you want an integrated backend API rather than building one yourself.

When self-hosting is the reason to move

Self-hosting gives you control over deployment and data placement. It also makes backups, upgrades, monitoring and recovery part of your operating plan.

PocketBase combines an embedded SQLite database with auth, file handling and realtime features. Its documentation warns that backward compatibility is not guaranteed before version 1.0 and advises caution for production-critical applications. Evaluate that stated limit against your project rather than presenting a small binary as an automatic production replacement. PocketBase documentation.

For any self-hosted backend, test restoration from backup and the upgrade path before depending on it. A process that starts successfully has not yet demonstrated data recovery.

Compare the complete cost model

Firestore billing can include document operations, storage and network use. Another product may charge by database compute, users, function usage or a base plan. Those units measure different things. Firestore billing documentation.

Record the same workload for each option: active users, reads, writes, stored data, file downloads, function execution and required environments. Add the plan you need for backups or other essential features. Use Firebase, Supabase, Appwrite and Lizard pricing as applicable.

Avoid calculating savings by comparing a database's entry plan with the whole Firebase bill. Also include development work: replacing client SDK calls and security rules can cost more than a small monthly hosting difference.

A migration plan that tests permissions

Inventory the Firebase products, SDK calls, security rules and identity providers in use.
Design the replacement data model and the access rules for each user role.
Import a test dataset. Check counts, identifiers, timestamps and representative application queries.
Test access as an anonymous user, a normal user and an administrator. Include denied reads and writes.
Test sign-in, sign-out, password recovery, file access and realtime updates where used.
Plan the final write transition, client release and rollback. Old mobile or browser clients may continue calling the old API.

On Lizard, a custom backend can use Managed Redis where appropriate and Managed Object Storage for files. Storage access policy must match the sensitivity of those files; do not assume a newly provisioned bucket is private.

FAQ

Is Lizard a direct Firebase replacement? Lizard can host your backend and data services. It does not automatically supply the Firebase client API, auth flows or security rules. Choose it when you want to run that server-side application.

Which alternative is closest to Firebase? It depends on which Firebase products you use. Compare actual APIs, auth, file access and realtime behaviour rather than selecting by a feature count.

Can I keep Firebase Authentication and move the database? You can design a backend that verifies the existing identity tokens. Check token verification and authorization carefully; accepting an identity is not the same as granting access to every record.

Will PostgreSQL remove all usage charges? No. The host still charges under its own plan for compute, storage, traffic or other services. The meter changes; the need to estimate the workload remains.

What is the most important migration test? Confirm that users can access exactly the records and files they should, and no others. Data import success alone does not prove correct permissions.

Originally published at Lizard (lizard.build).

Python app hosting: deploy Django, Flask and FastAPI

Yura Oak — Wed, 23 Sep 2026 12:03:21 +0000

Python app hosting starts with the process your application needs to run. Django and Flask commonly use a WSGI server; FastAPI uses an ASGI server. A Celery worker or a scheduled script has another lifecycle. Choose a host that supports those processes, the database and the storage your app needs.

Lizard (lizard.build) publishes this guide. We checked the linked framework and provider documentation on 9 September 2026. The examples use explicit module names that you must adapt to your project.

Choose the runtime before the host

Application	Production process	Other requirements to check
Django with WSGI	Gunicorn or another supported WSGI server	Database, migrations, static files and uploads
Django with async features	A supported ASGI server	Connection handling and compatibility of the app's dependencies
Flask	A production WSGI server	App import path or factory, secrets and database
FastAPI	Uvicorn or another ASGI server	Startup tasks, concurrency and database connections
Celery worker	A separate queue consumer	Broker, result backend if used, retries and shutdown
Script or batch job	A process that runs and exits	Schedule, timeout, exit status and durable output

The development server is for development. See the official Django deployment guide, Flask production guide and FastAPI worker guidance.

Python hosting options by need

Host	Why to consider it	Check before choosing
Lizard	Web services and workers with managed data services and CLI operations	Runtime settings, database wiring and measured resource use
Railway	Several services in a project	All service consumption and plan credit
Render	Published web and worker instance plans	Separate database cost and free-service restrictions
PythonAnywhere	A Python-focused hosting workflow	WSGI/ASGI support, outbound access and task limits on your plan
Cloud Run	HTTP services, jobs or worker pools	Resource type, billing mode, concurrency and cold starts
Fly.io	Machines in selected regions	Machine sizing, storage and network charges
DigitalOcean App Platform	Managed source or image deployment	Build support, app components and database pricing
Heroku	A familiar Python deployment workflow	Current plan, add-ons and product direction
A VPS	Direct server control	Updates, process management, TLS, backups and recovery

Use the PaaS comparison for the wider hosting decision. A Python badge in a feature table is not enough to confirm worker or database support.

Free Python hosting needs a workload limit

A free plan may restrict outbound requests, sleep an inactive web process, limit task execution or include only a trial credit. Those terms can be fine for a demonstration and unsuitable for a webhook receiver or queue worker.

Check Render's free-service rules and PythonAnywhere's free-account features. For Cloud Run, the pricing page describes free usage alongside billable resources. A database, image registry or network usage may remain outside the allowance you are looking at.

Test the first request after a quiet period and confirm whether scheduled or background work still runs. Describe the free option in terms of those limits, not as unlimited hosting.

Build and start commands

For a project that uses requirements.txt, install its pinned dependencies with:

python -m pip install -r requirements.txt

Use the package manager and lockfile already in your repository if it uses uv, Poetry or another tool. Include the production server in the dependencies. Do not rely on a package installed only on your laptop.

For Django, where myproject/wsgi.py defines the application:

gunicorn myproject.wsgi:application --bind "0.0.0.0:${PORT:-3000}"

For Flask, where app.py exports app:

gunicorn app:app --bind "0.0.0.0:${PORT:-3000}"

For FastAPI, where main.py exports app:

uvicorn main:app --host 0.0.0.0 --port "${PORT:-3000}"

These commands expect a shell to expand the port variable. A JSON-array Docker CMD does not expand it automatically. Either use the runtime's documented variable support, a shell wrapper, or a small program that reads the environment.

Set worker counts from measurements and available memory. More processes can use more memory and database connections; adding workers is not a substitute for checking a slow query or blocking task.

A minimal FastAPI container

For an application with main.py and a locked requirements.txt containing FastAPI and Uvicorn, this Dockerfile starts one server process:

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
RUN useradd --create-home appuser
USER appuser
EXPOSE 3000
CMD ["sh", "-c", "exec uvicorn main:app --host 0.0.0.0 --port ${PORT:-3000}"]

Choose a Python version compatible with your project. Put .env, local virtual environments, caches and Git data in .dockerignore. This example does not install extra operating-system packages; add only those your dependencies need.

On Lizard, you can bring a Dockerfile or use the source-build path. The deployment guide explains the options. Your app should expose a small health endpoint, and you should also test an endpoint that exercises its real dependencies.

A FastAPI deployment checked on Lizard

Our public FastAPI example has a dated deployment record from 9 September 2026. The test used commit df522c1, built from GitHub in eu-west-lim-a, with port 8000 and a Uvicorn start command in the Procfile. It used Python 3.13 with FastAPI 0.141.1 and Uvicorn 0.52.4. No manual build or start override was set.

The published check record reports six passing checks through the public HTTPS URL:

Request	Observed result
`GET /health`	HTTP 200 with `{"status":"ok"}`
`GET /docs`	HTTP 200; API interface uses `/openapi.json`
`GET /openapi.json`	HTTP 200; schema contains health and echo routes
`POST /echo` with a JSON object	HTTP 200 with the same object
`POST /echo` with a JSON array	HTTP 422 for the invalid body type
`GET /no-such-route`	HTTP 404

Open the live health endpoint, try the API interface, or follow the FastAPI deployment guide.

These results cover deployment and HTTP behaviour for a small app without a database. They do not measure uptime, load capacity or end-to-end deployment time. The same record gives a CLI reading at 11:48 UTC of about 0.034 GB of memory and about $0.00051/hour in resource cost. That is a reading at one moment, not a monthly invoice; the quoted reading used the rates in effect at the time. Current Lizard hosting uses pay as you go with no monthly subscription; storage, traffic and payment fees can add to the total. The Dockerfile above is a separate example and does not reproduce that deployment's exact configuration.

Django, Postgres and Celery need separate checks

Connect Managed Postgres through the variable your Django settings read. Run migrations as a controlled release step, not independently in every web worker. Configure static-file handling and give uploaded files durable storage.

Run Celery as a separate service with the same relevant application code and its own start command. Configure the broker explicitly, for example with Managed Redis if your application uses Redis. Check retries, duplicate-task handling and shutdown before accepting production work.

For a server you operate yourself, use the Django VPS walkthrough. For a managed worker, see the worker deployment reference.

Estimate the whole Python application

Include web processes, workers, database, stored files, backups, transfer and the plan your team needs. Railway meters consumption and applies its paid plan toward usage. Render publishes instance plans. PythonAnywhere currently lists Developer at $10/month; check its included features against your app. Sources: Railway, Render, PythonAnywhere.

Lizard has no monthly subscription or per-service plan fee. For a small app averaging 0.01 vCPU and 0.1 GB of memory over 720 hours, with 10 GB of egress, resource charges total about $1.53 before payment fees and tax. Add the database, worker and storage your Python app needs. See the worked example and current rates. Purchased credits do not expire, so a quiet month does not require buying another plan.

FAQ

Can I host FastAPI on the same services as Django? Often, but FastAPI needs an ASGI server. Confirm the host supports your start command and any long-lived connections or workers the app uses.

Should I use runserver in production? No. Use a production WSGI or ASGI server and check the framework's deployment guidance.

Why does the host say my app is unhealthy? Check the build logs, process exit status, import path, bound interface and expected port. Then check missing variables and dependency connections.

Do I need a Dockerfile? Not on every host. A source builder can create the image, but you still need correct dependencies and a production start command.

What is the best host for a Python worker? One that supports the worker's lifecycle and dependencies. Test queue consumption, retries and restart behaviour; an HTTP-only deployment is not enough.

Originally published at Lizard (lizard.build).