Skip to main content

Hosting & Infrastructure

Scottsdale Mint is hosted on Ymir, a serverless WordPress hosting platform built on AWS. Ymir manages Lambda function packaging, deployment, Aurora database provisioning, Redis cluster setup, S3 file storage, and CloudFront CDN configuration.

Request Flow​

All inbound traffic passes through the following layers before reaching WordPress on Lambda:

Visitor → Imperva WAF → Amazon CloudFront → AWS Lambda (WordPress)
  1. Imperva WAF — First line of defence. Filters malicious traffic, DDoS mitigation, bot management, and IP reputation checks before any request reaches AWS.
  2. Amazon CloudFront — CDN for performance. Caches static assets and cacheable pages at edge locations, handles SSL termination, and routes uncached requests to Lambda.
  3. AWS Lambda — Executes WordPress to generate the response.

CloudFront is used for performance and request routing, not as a security firewall. Security filtering is handled entirely by Imperva upstream.

Ymir Configuration (ymir.yml)​

The ymir.yml file at the repository root defines all infrastructure settings for every environment.

Production​

environments:
  production:
    domain: www.scottsdalemint.com
    architecture: x86_64
    concurrency: 800
    gateway: false
    deployment: image
    website:
      memory: 4096           # MB
      timeout: 120           # seconds
    console:
      memory: 1024
      timeout: 600
    database:
      server: scottsdalemint-aurora-prod
      name: wordpress
    cache: scottsdalemint-prod-v2
    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
    cron: 1
    warmup: 100
    build:
      commands:
        - composer install --no-dev
      include:
        - web/app/plugins/woocommerce

Staging & Development​

SettingStagingDevelopment
Domainstaging.scottsdalemint.comdev.scottsdalemint.com
Concurrency10080
Memory2048 MB2048 MB
Database Serverscottsdalemint-aurora-devscottsdalemint-aurora-dev
Database Namewordpress_stgwordpress_dev
Redisscottsdalemint-dev-v2scottsdalemint-dev-v2
Warmup40 requests20 requests

AWS Services Used​

AWS Lambda​

  • WordPress runs as Docker image-based Lambda functions (deployment: image) via Ymir's container runtime
  • Each request is a fresh Lambda invocation — no shared memory between requests
  • Lambda image is built from composer install --no-dev and includes the WooCommerce plugin bundle
  • Lambda runs in your AWS VPC to access Aurora and Redis privately

Amazon Aurora MySQL​

  • Production: scottsdalemint-aurora-prod — Dedicated Aurora cluster, database wordpress
  • Dev/Staging: scottsdalemint-aurora-dev — Shared Aurora cluster (wordpress_stg / wordpress_dev)
  • Aurora provides automatic failover, read replicas, and point-in-time restore
  • WordPress connects via DB_WRITER_HOST (writes) and DB_READER_HOST (reads)

Amazon S3​

  • Uploads: All media library uploads are served from S3 (Ymir manages this automatically)
  • KYC Documents: Customer identity verification documents are uploaded to a private S3 bucket
  • Lambda packages: Ymir stores Lambda deployment packages in S3

Valkey / Redis (ElastiCache)​

  • Production: scottsdalemint-prod-v2 — Dedicated Redis cluster
  • Dev/Staging: scottsdalemint-dev-v2 — Shared Redis cluster
  • Client: Relay (PHP extension for high-performance Redis; RESP3 protocol)
  • Compression: Zstandard (zstd) — fast, high-ratio compression
  • Serializer: igbinary — compact binary PHP object serialization
  • Use: Object cache (WP transients, WC sessions, query results), rate limiting

Amazon CloudFront CDN​

CloudFront sits between Imperva and Lambda. Its role is performance and request routing, not security:

  1. Static asset caching — CSS, JS, images served from edge locations
  2. HTML page caching — Product and category pages cached at edge
  3. Image processing — On-the-fly image resizing and optimization
  4. WooCommerce session awareness — Cookies whitelisted so logged-in cart state is preserved:
    • woocommerce_cart_hash
    • woocommerce_items_in_cart
    • woocommerce_recently_viewed
    • wp_woocommerce_session_*
  5. Cache bypass — Checkout, cart, and My Account are never cached at CDN
  6. Header forwarding — origin, authorization, x-http-method-override, x-wp-nonce

Cache Bypass Paths​

These paths always bypass CloudFront and hit Lambda directly:

  • /uploads/elementor/*
  • /addons
  • /cart
  • /checkout
  • /my-account

Cron Jobs​

WordPress cron is disabled (DISABLE_WP_CRON=1). Ymir runs scheduled WordPress cron tasks via its built-in cron system (cron: 1 in ymir.yml).

Critical scheduled tasks:

  • Price update endpoint is called by the external Laravel pricing middleware every minute (external cron, not Ymir)
  • WooCommerce order cleanup, email resend, etc. run via Ymir's cron runner

Deployment​

All deployments are triggered via Bitbucket Pipelines — developers do not run Ymir deploy commands locally. See the full Deployment Guide for details.

IP Address Handling​

The site sits behind both Imperva WAF and Amazon CloudFront. The web/wp-config.php file correctly resolves the real visitor IP:

// Priority 1: CloudFront viewer address header
// Priority 2: Imperva / proxy connecting IP header
// Fallback: REMOTE_ADDR (direct connection)

Always use WC_Geolocation::get_ip_address() in custom code — never use $_SERVER['REMOTE_ADDR'] directly, as it will return the CloudFront or Imperva edge server IP.

Environment Isolation​

Each environment (production, staging, development) is fully isolated:

  • Separate Aurora databases
  • Separate Redis clusters (dev/staging share one cluster with different key prefixes)
  • Separate S3 buckets for uploads
  • Separate CloudFront distributions
  • Separate Lambda function stacks

Plugin behavior also differs by environment — see Configuration: Environments for details.