Build and Deployment

Scottsdale Mint deploys WordPress to AWS Lambda via the Ymir serverless WordPress platform. All deployments are triggered manually through Bitbucket Pipelines custom pipelines — developers never run ymir deploy locally.

Deployment Environments

Environment	Domain	Ymir Environment
Production	`www.scottsdalemint.com`	`production`
Staging	`staging.scottsdalemint.com`	`staging`
Development	`dev.scottsdalemint.com`	`development`

Ymir Configuration (`ymir.yml`)

The ymir.yml file at the project root controls all infrastructure and deployment settings.

Project

id: 931
name: scottsdalemint
type: bedrock

Note: The project type is bedrock reflecting the Roots Bedrock WordPress framework structure.

Deployment Type

All environments use image-based deployment (deployment: image) — Ymir builds a Docker container image rather than a zip package.

Environment Summary

Setting	Production	Staging	Development
Architecture	x86_64	x86_64	x86_64
Lambda Concurrency	800	100	80
Website Memory	4096 MB	2048 MB	2048 MB
Website Timeout	120s	120s	—
Console Memory	1024 MB	1024 MB	1024 MB
Console Timeout	600s	600s	600s
Database Server	`scottsdalemint-aurora-prod`	`scottsdalemint-aurora-dev`	`scottsdalemint-aurora-dev`
Database Name	`wordpress`	`wordpress_stg`	`wordpress_dev`
Redis Cache	`scottsdalemint-prod-v2`	`scottsdalemint-dev-v2`	`scottsdalemint-dev-v2`
Warmup Requests	100	40	20
API Gateway	Disabled	Disabled	Disabled
Cron	Enabled	Enabled	Enabled

Build Configuration

build:
  commands:
    - 'composer install --no-dev'
  include:
    - web/app/plugins/woocommerce

The WooCommerce plugin is explicitly included in the build package because it is not managed via Composer — it is bundled directly.

CDN Configuration (identical across all environments)

cdn:
  caching: enabled
  process_images: enabled
  cookies_whitelist:
    - woocommerce_cart_hash
    - woocommerce_items_in_cart
    - woocommerce_recently_viewed
    - 'wp_woocommerce_session_*'
  excluded_paths:
    - '/uploads/elementor/*'
    - /addons
    - /cart
    - /checkout
    - /my-account
  forwarded_headers:
    - origin
    - authorization
    - x-http-method-override
    - x-wp-nonce

Bitbucket Pipelines (Primary Deployment Method)

All three deployment pipelines are defined as custom pipelines and must be manually triggered from the Bitbucket UI (Pipelines → Run Pipeline → select pipeline). They are not triggered automatically on branch push.

Runner

Pipelines run on a self-hosted Bitbucket runner with the self.hosted, x86, linux labels. The pipeline container uses the composer:2 Docker image with Docker-in-Docker available.

Theme Submodule

The suma-elementor theme is a git submodule. Each pipeline checks out the environment-specific release branch before deploying:

Pipeline	Submodule Branch
`development`	`release/development`
`staging`	`release/staging`
`production`	`release/production`

Pipeline Steps

Each pipeline performs the following steps:

Checks out the correct suma-elementor submodule branch for the target environment
Installs required PHP extensions (redis, zip, ftp) via apk and pecl
Runs composer install --no-scripts
Deploys via vendor/bin/ymir deploy <environment>

Production — Additional Post-Deploy Steps

After a successful deploy, the production pipeline also:

Purges the Imperva CDN cache via the Imperva API (site ID 91102551)
Waits 5 seconds for propagation
Triggers the NFusion pricing cache refresh by calling the internal pricing middleware endpoint

# Post-deploy cache invalidation (production only)
- curl -X POST "https://my.imperva.com/api/prov/v1/sites/cache/purge?site_id=..." \
    -H "x-API-Id: <IMPERVA_API_ID>" \
    -H "x-API-Key: <IMPERVA_API_KEY>"
- sleep 5
- curl http://<PRICING_MIDDLEWARE_HOST>:3000/refresh-cache

Credentials

The Imperva API ID, API Key, and pricing middleware host are stored as Bitbucket Repository Variables. Do not hardcode them.

How to Trigger a Deployment

Open the repository in Bitbucket
Navigate to Pipelines → Run Pipeline
Select the branch you want to deploy from
Under Pipeline, choose custom: development, custom: staging, or custom: production
Click Run

caution

Always deploy to development or staging first and verify before running the production pipeline. Production deployments go live immediately.

What Happens During a Ymir Deployment

Ymir builds a Docker image from the codebase (deployment: image)
Runs composer install --no-dev and bundles web/app/plugins/woocommerce
Pushes the image to Amazon ECR
Creates a new Lambda function version from the image
Updates the Lambda alias to point to the new version
Warmup requests are fired to pre-warm the Lambda pool
CloudFront cache is invalidated
(Production only) Imperva cache is purged and pricing cache is refreshed

Running Ymir CLI Commands (Admin / Debugging Only)

Ymir CLI is available locally via vendor/bin/ymir for administrative tasks. It is not used to trigger deployments.

# Execute a WP-CLI command on production
vendor/bin/ymir command production -- wp cache flush

# Tail Lambda logs
vendor/bin/ymir logs production --tail

# View recent logs
vendor/bin/ymir logs production

Composer Dependencies

# Install all dependencies (including dev)
composer install

# Install for production (no dev, optimized autoloader)
composer install --no-dev --optimize-autoloader

# Update a specific package
composer update package/name

# Apply patches after update
composer install  # cweagans/composer-patches applies automatically

Post-Deployment Checklist

After any production deployment:

Health check: https://scottsdalemint.com/wp-json returns 200
WooCommerce is active and products are loading
Algolia search is functioning
Pricing pipeline is updating product prices (check a product price)
Checkout page loads without JavaScript errors
CloudFront cache is serving static assets
New Relic is receiving APM data
Imperva cache purge completed (check pipeline logs)

Rollback

Ymir supports rollback to a previous Lambda version:

vendor/bin/ymir rollback production

This immediately switches the Lambda alias back to the previous image version — no redeployment needed.

Deployment Environments​

Ymir Configuration (ymir.yml)​

Project​

Deployment Type​

Environment Summary​

Build Configuration​

CDN Configuration (identical across all environments)​

Bitbucket Pipelines (Primary Deployment Method)​

Runner​

Theme Submodule​

Pipeline Steps​

Production — Additional Post-Deploy Steps​

How to Trigger a Deployment​

What Happens During a Ymir Deployment​

Running Ymir CLI Commands (Admin / Debugging Only)​

Composer Dependencies​

Post-Deployment Checklist​

Rollback​