How to redeploy after changing an AI-built app | Ample

The short version

After changing an AI-built app, run the same Ample deploy workflow again. Ample hashes the packaged files, build configuration, and environment, then compares them with the live release. A real change creates a new release. No change returns unchanged: true and the current live URL without rebuilding.


Before you start

This guide is for builders shipping a second or later version of an app that is already live on Ample.


How to do it

  1. Make and verify the change
    Ask the coding agent to run the smallest relevant local check before deployment. Commit the change if that is part of your repo workflow.

  2. Reuse the recorded plan
    If the repo has ample.toml, keep it aligned with any service, database, volume, domain, or environment changes.

  3. Deploy once
    For a single service, run ample deploy. For a planned multi-service topology, run ample up so dependencies are applied in order.

    ample deploy
    
  4. Read unchanged correctly
    An unchanged result is a successful no-op. It means the live release already matches the packaged content and deployment configuration.

  5. Force only for intentional reactivation
    Use force when unchanged source must be rebuilt and reactivated, such as recovering a live release that is misbehaving at runtime.

    ample deploy --force
    

What this supports

Good fit

Know the limits


Common failure modes

The deploy says unchanged but you expected new code

Confirm the edited file is inside the deploy root and is not excluded from packaging.

The new release fails

Read its build or runtime logs, fix the cause, and deploy the changed source.

A prior start command disappeared

Check the saved config or ample.toml and pin the intended start command when detection is not sufficient.