Optimizing for the "Always Free" Tier: A Build-and-Deploy Strategy for XSS Hunter

In the world of security research and hobbyist dev-ops, the goal is often to achieve production-grade reliability on a zero-dollar budget. Recently, I set out to migrate a fresh instance of XSS Hunter Express to Google Cloud Platform (GCP).

While GCP's "Always Free" tier is generous, it presents a significant hurdle: the e2-micro instance's 1GB of RAM is insufficient for the resource-intensive docker build process. Attempting to compile the Node.js stack on-box inevitably leads to OOM (Out of Memory) freezes and system instability.

Here is the "Build Big, Run Small" workflow I used to bypass these hardware constraints and deploy a permanent, SSL-secured lab for exactly $0.00/month.

1. The Ephemeral Builder Pattern

The core of the strategy is decoupling the Build environment from the Host environment. I provisioned a temporary e2-medium (4GB RAM) to act as a high-performance workshop.

This environment handled the heavy lifting—dependency resolution and image compilation—without the risk of system freezes. Once the image was finalized and pushed to a registry, the instance was decommissioned to stop the billing clock. Treating infrastructure as disposable in this way is a key DevOps principle that translates perfectly to personal cost-saving.

2. Decoupling with Artifact Registry

To move the finished application to the micro-instance, I utilized GCP Artifact Registry as a central "Cloud Warehouse." Transitioning between environments highlighted two common friction points that often trip up engineers:

IAM Scopes & Registry Access: Registry access is not granted to your VM by default. I had to explicitly bind the artifactregistry.writer role to the service identity to allow the push.

The Sudo Credential Disconnect: A common pitfall occurs when authenticating with gcloud as a standard user but executing docker push with sudo. To resolve this, the root user's Docker configuration must be updated specifically:

sudo gcloud auth configure-docker northamerica-northeast1-docker.pkg.dev

3. Engineering for $0.00 Persistence

Provisioning the "Free Tier" host requires meticulous attention to the console's default settings, which often favor performance over cost-savings.

The "Always Free" Specification:

• Region Selection: Limited to us-central1, us-west1, or us-east1.
• Machine Type: e2-micro.
• Disk Selection: Google defaults to "Balanced" or "SSD" persistent disks. To hit the $0.00 mark, I manually downgraded the boot disk to a Standard Persistent Disk (limited to 30GB).

Persistence & Docker Volumes

In this architecture, the container is disposable. To ensure that the PostgreSQL database—and my captured payloads—survive a container update, I mapped the data directory to a named volume in the docker-compose.yml. This ensures that state is stored on the persistent disk independently of the container lifecycle.

4. Connectivity: Static IPs and the SSL Catch-22

A security tool is useless if the callback domain is broken. I mapped my domain, pxss.eu, to the new VM, but this introduced two critical steps:

Static IP Anchoring: By default, external IPs are ephemeral. To prevent DNS breakage during maintenance or reboots, I "promoted" the IP to Static. In GCP, a static IP is free as long as it is attached to a running instance.

DNS Synchronization: XSS Hunter uses Let's Encrypt (via Greenlock) for automated SSL. The ACME challenge will fail if the container starts before DNS propagation is complete. I monitored resolution via dig pxss.eu +short and only initialized the Docker stack once the A-record was confirmed globally.

5. Performance Safeguards: The Swap File Hack

Running a database and a web app on 1GB of RAM is tight. To prevent the Linux kernel's OOM (Out of Memory) Killer from terminating my processes during occasional spikes, I implemented a small swap file on the persistent disk.

While swap on cloud storage isn't optimal for high-performance apps, for a low-traffic security lab, it acts as a vital safety net that keeps the service alive when RAM usage hits the ceiling.

6. The "Penny Sentry" Strategy

Even on a free tier, network egress can accrue costs. Google allows for 1GB of data transfer per month. To protect against unexpected traffic or log spikes, I implemented a GCP Budget Alert at the $0.01 USD threshold.

This acts as a "tripwire" notification rather than a kill-switch, providing the peace of mind needed to run "free" infrastructure without checking the billing dashboard every morning.

Conclusion

The beauty of this architecture isn't just the $0.00 price tag; it's the clean separation of concerns. The medium-tier VM is the disposable workshop, the Artifact Registry is the versioned library, and the e2-micro is the rugged, low-cost edge.

By treating the cloud as a series of modular tools rather than a single expensive server, we gain reliability, easier updates, and a much deeper understanding of the underlying billing and deployment logic.

Summary Checklist for a Successful Deployment:

• Build Big: Use an e2-medium for compilation to avoid OOM freezes.
• Warehouse: Push images to Artifact Registry; remember to authenticate the root user for Docker.
• Host Small: Use an e2-micro with a Standard disk in a Free Tier region.
• Anchor: Promote your Ephemeral IP to Static to protect your DNS.
• Monitor: Set a $0.01 budget alert to catch any egress overages before they scale.