Credentials

The plugin needs permission to create and manage cloud resources on your behalf. Credentials can be supplied via environment variables, a config file, or inline in config.json. Environment variables are recommended for CI/CD pipelines; inline config is convenient for local development.

Never commit credentials to source control. Use environment variables or a secrets manager in CI/CD pipelines.

AWS Credentials

The plugin uses the standard AWS credential chain. Any of the following methods work.

Method 1 — Environment Variables (recommended for CI/CD)

export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
export AWS_DEFAULT_REGION=eu-west-2

Method 2 — AWS Credentials File

Configure a named profile in ~/.aws/credentials:

[myapp-deploy]
aws_access_key_id     = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
region                = eu-west-2

Then reference the profile in your config:

{
  "credentials": {
    "method": "profile",
    "profile": "myapp-deploy"
  }
}

Method 3 — Inline in config.json

{
  "credentials": {
    "method": "static",
    "accessKeyId": "${AWS_ACCESS_KEY_ID}",
    "secretAccessKey": "${AWS_SECRET_ACCESS_KEY}",
    "region": "eu-west-2"
  }
}

Use variable substitution (${...}) so the actual values come from environment variables, not the file.

Method 4 — IAM Role (EC2 / ECS / Lambda)

When running on an AWS compute resource with an attached IAM role, no credential configuration is needed. The plugin picks up the instance metadata credentials automatically.

Minimum IAM Permissions

The IAM user or role must have permission to create and manage the resources for each component type you use. The table below lists the minimum AWS managed policies or equivalent custom permissions.

Component	Required permissions (actions)
function	lambda:CreateFunction, lambda:UpdateFunctionConfiguration, lambda:UpdateFunctionCode, lambda:GetFunction, lambda:GetFunctionConfiguration, lambda:TagResource, iam:CreateRole, iam:GetRole, iam:TagRole, iam:PutRolePolicy, iam:PassRole, sts:GetCallerIdentity, logs:CreateLogGroup, and (only when a function declares a schedule) events:PutRule, events:PutTargets, events:DeleteRule, events:RemoveTargets, events:ListTargetsByRule, lambda:AddPermission
api-gateway	apigateway:, acm:RequestCertificate, acm:DescribeCertificate, route53:ChangeResourceRecordSets*
website	s3:, cloudfront:, acm:RequestCertificate, route53:ChangeResourceRecordSets, and secretsmanager:GetSecretValue (only when an accessGate is enabled)
database	dynamodb:CreateTable, dynamodb:DescribeTable, dynamodb:TagResource, and (only when a table declares a ttlAttribute) dynamodb:DescribeTimeToLive, dynamodb:UpdateTimeToLive
storage	s3:*
authentication	cognito-idp:, and lambda:AddPermission* (only when Cognito Lambda triggers are declared, to let the pool invoke the trigger functions)
email	ses:*
sms	sns:*
event-bus	events:, lambda:AddPermission*

Function-to-function links. When a function declares a FUNCTION_TO_FUNCTION link, the plugin injects the target function's ARN as a FUNCTION_<NAME> environment variable. Resolving that ARN requires lambda:GetFunctionConfiguration (and lambda:GetFunction) so the variable is populated even when the target function was unchanged and therefore skipped in the current deploy. Creating a function with its execution role also requires iam:PassRole. If you scope your policy narrower than lambda:*, make sure these read actions are included or the linked ARN will be silently omitted.

Website access gate. When a website component enables an accessGate (edge HTTP Basic auth), the deploy identity additionally needs secretsmanager:GetSecretValue to read the credentials secret at deploy time, and the CloudFront function actions cloudfront:CreateFunction, cloudfront:UpdateFunction, cloudfront:PublishFunction, cloudfront:DescribeFunction, and cloudfront:DeleteFunction (all covered by cloudfront:*). If you scope secretsmanager:GetSecretValue by resource, include the ARN of the secret named in accessGate.credentialsSecret.

Website edge functions. When a website declares an edgeFunctions viewer-request entry, the deploy identity needs the CloudFront function actions cloudfront:CreateFunction, cloudfront:UpdateFunction, cloudfront:PublishFunction, cloudfront:DescribeFunction, and cloudfront:DeleteFunction — all already covered by cloudfront:*. Edge functions read their source from the project at deploy time and need no Secrets Manager access (unlike the access gate).

CI/CD Example (GitHub Actions)

- name: Deploy
  env:
    AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
    AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    AWS_DEFAULT_REGION: eu-west-2
  run: mvn serverless:deploy

Azure Credentials

The plugin authenticates using a Service Principal. Create one with the Azure CLI:

az ad sp create-for-rbac \
  --name "serverless-plugin-deploy" \
  --role Contributor \
  --scopes /subscriptions/{subscriptionId}/resourceGroups/{resourceGroup} \
  --sdk-auth

This outputs a JSON block containing clientId, clientSecret, tenantId, and subscriptionId.

Method 1 — Environment Variables (recommended for CI/CD)

export AZURE_CLIENT_ID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
export AZURE_CLIENT_SECRET=your-client-secret
export AZURE_TENANT_ID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
export AZURE_SUBSCRIPTION_ID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Method 2 — Inline in config.json

{
  "credentials": {
    "method": "service-principal",
    "clientId": "${AZURE_CLIENT_ID}",
    "clientSecret": "${AZURE_CLIENT_SECRET}",
    "tenantId": "${AZURE_TENANT_ID}",
    "subscriptionId": "${AZURE_SUBSCRIPTION_ID}"
  }
}

Minimum RBAC Roles

Component	Required role(s)
function	Contributor on the resource group, Storage Blob Data Contributor
api-gateway	Contributor (API Management), DNS Zone Contributor
website	Contributor (Static Web Apps), DNS Zone Contributor
database	Contributor (Cosmos DB / Table Storage)
storage	Storage Blob Data Contributor
authentication	B2C IEF Policy Administrator (Azure AD B2C)
email	Contributor (Communication Services)
sms	Contributor (Communication Services)
event-bus	EventGrid Contributor

CI/CD Example (GitHub Actions)

- name: Deploy
  env:
    AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
    AZURE_CLIENT_SECRET: ${{ secrets.AZURE_CLIENT_SECRET }}
    AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
    AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
  run: mvn serverless:deploy

GCP Credentials

The plugin uses a Service Account key. Create a service account and download a JSON key:

# Create service account
gcloud iam service-accounts create serverless-plugin-deploy \
  --display-name "Serverless Plugin Deploy"
 
# Grant roles (repeat for each needed role)
gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member="serviceAccount:serverless-plugin-deploy@YOUR_PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/editor"
 
# Download key
gcloud iam service-accounts keys create key.json \
  --iam-account=serverless-plugin-deploy@YOUR_PROJECT_ID.iam.gserviceaccount.com

Method 1 — Environment Variable (recommended for CI/CD)

export GOOGLE_APPLICATION_CREDENTIALS=/path/to/key.json

Method 2 — Inline in config.json

{
  "credentials": {
    "method": "service-account-key",
    "keyFile": "${GCP_KEY_FILE_PATH}",
    "projectId": "your-gcp-project-id"
  }
}

Minimum IAM Roles

Component	Required role(s)
function	roles/cloudfunctions.developer, roles/iam.serviceAccountUser
api-gateway	roles/apigateway.admin, roles/dns.admin
website	roles/storage.admin, roles/compute.loadBalancerAdmin, roles/dns.admin
database	roles/datastore.owner
storage	roles/storage.admin
authentication	roles/firebase.admin
email	Secret Manager Secret Accessor (for SendGrid key)
sms	Secret Manager Secret Accessor (for Twilio key)
event-bus	roles/pubsub.admin

CI/CD Example (GitHub Actions)

- name: Authenticate to GCP
  uses: google-github-actions/auth@v2
  with:
    credentials_json: ${{ secrets.GCP_CREDENTIALS_JSON }}
 
- name: Deploy
  run: mvn serverless:deploy -DprojectId=your-gcp-project-id

Credentials Object Reference

The optional credentials block at the root of config.json supports these fields:

Field	Type	Required	Description
method	string	required	One of: env (default), profile (AWS), static (AWS), service-principal (Azure), service-account-key (GCP).
region	string	optional	AWS only. Overrides the region for credential resolution. Normally set per-region in the regions array.
profile	string	optional	AWS only. Named profile from ~/.aws/credentials.
accessKeyId	string	optional	AWS static credentials. Use variable substitution.
secretAccessKey	string	optional	AWS static credentials. Use variable substitution.
clientId	string	optional	Azure service principal client ID.
clientSecret	string	optional	Azure service principal client secret. Use variable substitution.
tenantId	string	optional	Azure tenant ID.
subscriptionId	string	optional	Azure subscription ID.
keyFile	string	optional	GCP path to service account JSON key file. Use variable substitution.
projectId	string	optional	GCP project ID. Can also be set via GCLOUD_PROJECT environment variable.

If the credentials block is omitted entirely, the plugin falls back to the provider's default credential chain — environment variables, then credential files, then instance metadata. This is the recommended approach for most CI/CD setups.