The action finds or creates Serverless Function in the given folder in Yandex Cloud and deploys new version.

• Usage
• Permissions
• Development
• License Summary

- name: Deploy Function
  id: sls-func
  uses: yc-actions/yc-sls-function@v5
  with:
      yc-sa-json-credentials: ${{ secrets.YC_SA_JSON_CREDENTIALS }}
      bucket: ${{ secrets.BUCKET }}
      folder-id: 'b1g*********'
      function-name: 'test-function'
      runtime: 'nodejs16'
      memory: '256Mb'
      entrypoint: 'src/main.handler'
      environment: |
          DEBUG=True
          COUNT=1
      include: |
          ./src
          package.json
      exclude: |
          **/*.ts
      tags: |
          ${{ GITHUB_SHA::6 }}
          foo
      secrets: |
          DB_PASSWORD=lockbox-secret-id/latest/password
          API_KEY=lockbox-secret-id/abcdef123456/api_key

You can specify Lockbox secrets for your function using the secrets input. The format is:

<ENV_VAR>=<lockbox-secret-id>/<version-id>/<key>

New Feature:

• You can now use latest as the <version-id> to automatically use the most recent version of the secret at deploy time.

• Example:

  secrets: |
      DB_PASSWORD=lockbox-secret-id/latest/password
      API_KEY=lockbox-secret-id/abcdef123456/api_key

  In this example, DB_PASSWORD will always use the latest version of the secret, while API_KEY uses a specific version.

Note: If latest is specified and no versions are found for the secret, the deployment will fail with an error.

The <lockbox-secret-id> position also accepts the secret's name, so you can write a workflow that stays readable and survives the secret being recreated:

secrets: |
    DB_PASSWORD=my-database-credentials/latest/password
    API_KEY=lockbox-secret-id/latest/api_key

The action first tries the value as a secret ID. Only if that lookup fails does it list the secrets in folder-id and match by name, so ID-based workflows are unaffected and pay no extra API call.

Only latest references can use a name. A reference pinned to an explicit version ID is passed straight to the API and must use the secret ID. A name is looked up only in folder-id; a secret in another folder must be referenced by ID.

Note: Resolution happens at deploy time, so the name lookup needs the lockbox.viewer role on folder-id for the credentials the action itself authenticates with (yc-sa-json-credentials, yc-iam-token or yc-sa-id) — not for the function's service-account. See Deploy time permissions.

Each line in the mounts input should be in the form:

<mount-point>:<bucket>[/<prefix>][:ro]

• mount-point (required): Directory name to mount the bucket to (will be available as /function/storage/<mount-point>).
• bucket (required): Name of the Object Storage bucket.
• prefix (optional): Prefix within the bucket to mount (leave empty to mount the entire bucket).
• ro (optional): If present, mount is read-only. Otherwise, mount is read-write.

Examples:

data:my-bucket
images:my-bucket/photos
logs:my-bucket:ro
images:my-bucket/photos:ro
mount:bucket/prefix
mount:bucket/prefix:ro

- name: Deploy Function with Object Storage Mount
  uses: yc-actions/yc-sls-function@v5
  with:
      mounts: |
          data:my-bucket
          images:my-bucket/photos
          logs:my-bucket:ro
          images:my-bucket/photos:ro
          mount:bucket/prefix
          mount:bucket/prefix:ro

One of yc-sa-json-credentials, yc-iam-token or yc-sa-id should be provided depending on the authentication method you want to use. The action will use the first one it finds.

• yc-sa-json-credentials should contain JSON with authorized key for Service Account. More info in Yandex Cloud IAM documentation.
• yc-iam-token should contain IAM token. It can be obtained using yc iam create-token command or using yc-actions/yc-iam-token-fed

- name: Get Yandex Cloud IAM token
  id: get-iam-token
  uses: docker://ghcr.io/yc-actions/yc-iam-token-fed:1.0.0
  with:
      yc-sa-id: aje***

• yc-sa-id should contain Service Account ID. It can be obtained using yc iam service-accounts list command. It is used to exchange GitHub token for IAM token using Workload Identity Federation. More info in Yandex Cloud IAM documentation.

To make the function be able to be invoked asynchronously, you need to set the async input parameter to true.

- name: Deploy Function
  id: sls-func
  uses: yc-actions/yc-sls-function@v5
  with:
      yc-sa-json-credentials: ${{ secrets.YC_SA_JSON_CREDENTIALS }}
      bucket: ${{ secrets.BUCKET }}
      folder-id: 'b1g*********'
      function-name: 'test-function'
      runtime: 'nodejs16'
      memory: '256Mb'
      entrypoint: 'src/main.handler'
      environment: |
          DEBUG=True
          COUNT=1
      include: |
          ./src
          package.json
      exclude: |
          **/*.ts
      tags: |
          ${{ GITHUB_SHA::6 }}
          foo
      async: true

Also, you can provide additional parameters for async invocation:

See action.yml for the full documentation for this action's inputs and outputs.

To perform this action, the service account on behalf of which we are acting must have the functions.editor role or higher.

Additionally, you may need to grant the following optional roles depending on your specific needs:

The service account provided to function via service-account parameter must have the following roles:

This action requires Node.js 24 to build and test.

• npm run bundle — format the repository and rebuild dist/index.js. Run this before committing any change under src/, since dist/ is what GitHub Actions executes.
• npm test — run the Jest suite.
• npm run lint — run ESLint.
• npm run local-action — run the action locally against a .env file. Copy .env.example to .env, fill in credentials and inputs, then run the command.

This code is made available under the MIT license.