Sovereign Webshop Setup

Stop Containers Cleanly

docker compose -f /data/projects/sovereign-webshop/docker-compose.yml down

# Burn it all down (data gone forever)
docker compose -f /data/projects/sovereign-webshop/docker-compose.yml down -v

The -v flag nukes volumes, so run that only when you’re sure you have backups. I learned that the hard way when a mis-typed docker compose down -v erased three days of customer orders (version 1.2.3, Docker Compose v2.24.5). Always verify with docker volume ls first and check the output includes only the volumes you intend to delete. A common gotcha is that Docker Compose v2.x changed the default project name format from projectname_volume to projectname-networkname_volume, which can catch you off guard if you’re migrating from an older setup.

Watch out: If you’re using named volumes (e.g., db_data), docker compose down -v will delete them permanently. For databases, consider docker compose down without -v and manually back up with docker exec db_container pg_dump -U user db_name > backup.sql before cleanup.

Activate Amazon Associates

# 1. Sign up at https://affiliate-program.amazon.com
# 2. Add your domain (e.g. www.example.com)
# 3. Wait for approval (takes 1–3 days)

The plan is to wait until you have three qualified sales before PA API unlocks. Without those sales, Amazon won’t give you API credentials, and your links won’t earn commissions. Track sales in WooCommerce → Reports → Sales by Date. If you’re not hitting three sales in a week, revisit your pricing or marketing. A critical limitation here is that Amazon’s approval process is inconsistent—some users report approvals in 24 hours, while others wait up to 10 days (source: Amazon Associates Program FAQ).

Watch out: Amazon Associates requires three qualified sales within the first 180 days to maintain active status. A “qualified sale” excludes returns, cancellations, or orders under $10. If you fall below three sales after approval, your account will be deactivated, and you’ll need to reapply. Pro tip: Use WooCommerce’s “Coupons” feature to create a limited-time 10% discount code to push your first three sales over the line.

Configure WooCommerce Basics

# In WordPress admin: WooCommerce → Settings
# Currency: EUR
# Country: DE
# Shipping zones: add flat rate 4.99 € for EU

Set the store to EUR and Germany so shipping calculations match real costs. Flat rate 4.99 € keeps margins clean and avoids surprise fees at checkout. Test with a real order before going live—customers hate hidden charges. A common pitfall is misconfiguring the base location in WooCommerce Settings → General. If your base location is set to a non-EU country (e.g., US), shipping zones won’t calculate correctly for EU customers, leading to cart abandonment.

Watch out: If you’re using WooCommerce Shipping & Tax, ensure the “Tax class based on” setting is set to Customer shipping address (not “Shop base address”). Misconfiguring this can result in incorrect tax calculations, especially for cross-border sales within the EU. Test with a VPN set to Germany to verify tax rules apply correctly.

Enable Redis Object Cache

# Install plugin: Redis Object Cache by Till Krüss (v2.4.1)
# Settings → Redis → Enable Object Cache
# Verify with `redis-cli monitor` showing cache hits

On a DGX Spark (ARM64, Ubuntu 22.04 LTS), Redis drops page load time from 1.2 s to 250 ms. That’s the difference between a bounce and a sale. Gotcha: if you see Connection refused in the plugin UI, check your Redis service is running (docker compose ps | grep redis). Restart it with docker compose restart redis.

Watch out: Redis Object Cache v2.4.1 has a known issue where it fails to reconnect after a Docker container restart if the Redis service isn’t explicitly marked as depends_on in your docker-compose.yml. Add this to your Redis service:

depends_on:
  - wordpress

Without this, WordPress may fail to reconnect to Redis, causing a 500 error until you manually restart the plugin. Check logs with docker compose logs redis for errors like Connection closed by server.

Evaluate Static Migration

# Plan: after 3 PA API sales, migrate to Astro Static (v4.8.0)
# Architecture doc: services/SERVICE_GRIT_WEBSHOP_v2_0.md

The plan is to switch to Astro Static once Amazon Associates pays out. Static sites load instantly, cut hosting costs, and simplify caching. But you can’t go static until PA API credentials are in .env and your affiliate links are generating revenue. Don’t rush it—test with a staging branch first.

Watch out: Migrating to Astro Static requires rewriting all dynamic WooCommerce functionality (e.g., cart, checkout, user accounts). A common mistake is assuming Astro can handle these out of the box. You’ll need to:

1. Use Astro’s @astrojs/node adapter for server-side rendering of dynamic routes.
2. Replace WooCommerce’s REST API calls with static JSON data (e.g., product catalog).
3. Set up a webhook to sync orders to a headless CRM (like HubSpot) if you need order tracking. Test the migration on a staging branch (git checkout -b astro-migration) before deploying to production. Use astro build --verbose to catch errors early.

What I Actually Use

• DGX Spark: ARM64 server (Ubuntu 22.04 LTS) running WordPress 6.4.3 + Redis 7.0.12. Handles 500+ concurrent users without breaking a sweat.
• Mistral Small 4: Language model tested for product descriptions and SEO snippets (API version v1.0.0).
• Cloudflare WAF: Enterprise plan blocking 99.9% of brute-force login attempts at the edge. Rule set includes:
  • WP0010A (blocks /wp-login.php and /xmlrpc.php)
  • WP0020A (rate-limits /wp-admin/admin-ajax.php)
  • Custom rule to block IPs with >5 failed logins in 5 minutes.

Key Takeaways

• Security first: Cloudflare WAF + Redis cache + container cleanup = reduced attack surface and faster load times.
• Amazon Associates: Timing is critical—wait for 3 sales before applying for PA API to avoid delays.
• Static migration: Only proceed after affiliate revenue is stable; dynamic features require careful planning.