A deployment can complete while a user's request still fails. Review an agent-built release at three layers: the selected deployment path, the data connection, and behavior on the real URL.
We are the team behind Lizard (lizard.build). Our October 8 announcement describes deploying from a terminal or GitHub, managed data services, and live logs and metrics.
At the deployment layer, identify how this service receives code. A local-folder upload with lizard up differs from a GitHub-linked service. For an existing GitHub-linked app, use its repository workflow; do not replace that workflow with a local upload just because the agent can run a command. Record the deployed revision.
At the data layer, provision Managed Postgres explicitly if the app needs it, connect the consuming service, and apply the application's migrations. The documented command lizard add postgres creates the database resource; it is not an application migration or a complete connection check.
At the behavior layer, perform a harmless write and read on the public URL. For a hypothetical issue tracker, create an issue, reload it, and check access from another test account. Record results rather than declaring success from the build output.
If behavior fails, align the request time with service logs and resource metrics. Ask the agent to investigate the evidence and propose a bounded change, then repeat the failed action. Human review remains necessary for authorization rules, secrets, and recovery.
October 8 announcement · Lizard documentation · Explore Lizard
Responses
Join the conversation
Sign in to share your thoughts and interact with the author.
Sign In to Comment