Skip to content

Feature request: sam build/deploy should zip and upload local CodeUri for AWS::Serverless::MicrovmImage, like it does for Function #9283

Description

@singledigit

Describe your idea/feature/enhancement

I wish sam build/sam deploy would accept a local directory path for AWS::Serverless::MicrovmImage.CodeUri, zip it, and upload it to SAM's managed S3 bucket automatically — the same local-file handling sam already provides for AWS::Serverless::Function.CodeUri.

Today MicrovmImage.CodeUri only accepts an S3 URI (per the SAM Spec docs: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-microvmimage.html — Required: Yes, described as "The Amazon S3 URI of the zip artifact", every example uses s3://... directly). sam build passes a local path straight through unchanged instead of zipping/uploading it — there's no equivalent of the local-file auto-upload SAM already does for Function.

Proposal

Extend the same local-file handling sam build/sam package/sam deploy already use for Function.CodeUri to also cover MicrovmImage.CodeUri:

  • sam build zips the local directory (respecting .samignore/exclude patterns like Function build does).
  • sam package/sam deploy uploads the zip to the resolved S3 bucket (via --resolve-s3 or an explicit --s3-bucket) and rewrites CodeUri to the resulting S3 URI in the transformed template, exactly like it does today for Functions.
  • Ideally, content-hash the uploaded key the same way Function artifacts are hashed, so CloudFormation reliably detects real code changes (right now, anyone hand-rolling their own S3 upload for MicrovmImage has to replicate this themselves to avoid uploading to a fixed key that never changes — CloudFormation only diffs property values, so a stable key silently no-ops rebuilds on a real code change unless the key itself changes).

Things to consider:

  1. Will this require any updates to the SAM Spec (https://github.com/aws/serverless-application-model)? Likely not much beyond documentation — CodeUri's type/shape doesn't need to change, only sam build/sam package need to recognize a local path for this resource type and handle it the way they already do for Function.
  2. This directly unblocks a related bootstrap problem: today, any template where MicrovmImage.CodeUri needs a value from the same stack's own outputs (e.g. the artifact needs an id baked in from a resource this stack creates) can't be deployed at all on a fresh account — there's no existing S3 object to reference on a first-ever deploy, and CloudFormation validates the changeset (rejecting the missing/invalid CodeUri) before creating anything, including any bucket. I filed the underlying resource-behavior side of that as AWS::Serverless::MicrovmImage.CodeUri has no default and no local-file support, making a required-parameter bootstrap deploy impossible serverless-application-model#3995 — this CLI-side local-file support would make that whole class of problem go away for most users, the same way it already doesn't come up for Function.
  3. Precedent: Feature request: AWS::Serverless::Function.ImageUri Should Also Accept a Local File Path #6909 requested similar local-file handling for Function.ImageUri (container images) — this request is the equivalent gap for MicrovmImage.CodeUri specifically.

Additional Details

Hit this building a public sample project (https://github.com/singledigit/microvm-dev-environment) that uses AWS::Serverless::MicrovmImage. We ended up hand-rolling exactly the zip+hash+upload logic this request describes inside our own deploy script, purely to work around sam build not doing it for us. Happy to share that script as a reference for the expected behavior if useful.

sam --version: SAM CLI, version 1.161.0

Activity

  1. dothomson commented on Oct 13, 2026

    @dothomson

    With the introduction of AWS::Serverless::WebFunction I hope this can also be extended there also!

  2. reedham-aws commented on Oct 14, 2026

    @reedham-aws
    Contributor

    @dothomson, I believe WebFunction support is being worked on in #9340.

  3. proton0210 commented on Oct 15, 2026

    @proton0210

    I am taking this on. I will focus on local MicrovmImage CodeUri packaging through the existing artifact hashing/upload path, preserve S3 references, and add build/package regression coverage. I will keep this separate from the WebFunction work in #9340 and document any build or template-spec limitations in the PR.

  4. proton0210 commented on Oct 15, 2026

    @proton0210

    Implemented in #9346. Local MicrovmImage CodeUri directories/ZIPs now use the existing hashed S3 packaging path, and sam build preserves the source reference when relocating templates. Missing CodeUri does not implicitly package the template directory. Three audit passes completed; make pr passed with 9,440 unit tests and 94.15% coverage, plus 11 functional tests and 2 CLI build integration tests. The live S3 packaging test is added for CI but was not run locally. The PR documents service-side build behavior and the existing archive/exclusion limitations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions