Deploying a Receipt Management System to quickdumpnow.com: S3, CloudFront, and Custom Error Handling

This post covers the deployment of a new receipts page for a trailer rental business at quickdumpnow.com/books, including S3 object management, CloudFront distribution configuration, and DNS routing decisions.

What Was Done

We deployed a dedicated receipt management interface to quickdumpnow.com/books by:

  • Creating and updating /Users/cb/Documents/repos/sites/quickdumpnow.com/books/index.html with a new receipts form interface
  • Updating /Users/cb/Documents/repos/sites/quickdumpnow.com/robots.txt to block the /books path from search engine crawling
  • Uploading both the books/index.html file and a bare books key to S3 for pretty URL routing
  • Invalidating CloudFront cache for the affected paths to ensure immediate availability
  • Diagnosing and understanding the existing custom error response configuration

Technical Details: File Structure and Deployment

The local repository structure for this project follows a standard static site layout:

/Users/cb/Documents/repos/sites/quickdumpnow.com/
├── index.html (homepage)
├── books/
│   └── index.html (receipts page)
└── robots.txt

The books/index.html file was created to serve as the receipts management interface. Since this is a business tool (not a public-facing page), we added a directive to robots.txt to prevent indexing:

User-agent: *
Disallow: /books

This ensures search engines won't crawl or index the receipts management system, keeping it as an internal business tool rather than discoverable content.

S3 and CloudFront Configuration

The site is hosted on S3 with CloudFront as the CDN layer. When deploying the new receipts page, we needed to account for how S3 and CloudFront handle pretty URLs (paths without file extensions).

S3 Object Keys:

We uploaded the content to two keys to ensure both URL patterns work correctly:

  • books/index.html — The traditional nested structure; CloudFront's origin can be configured to automatically append index.html when accessing directory paths
  • books — A bare key without extension, providing a direct object match for /books requests

This dual-upload approach ensures that whether a request comes in as /books or /books/, CloudFront finds a matching object. The bare books key acts as a fallback, eliminating reliance solely on S3's directory index behavior.

CloudFront Invalidation:

After uploading, we invalidated the CloudFront distribution cache for these paths:

/*
/books
/books/
/robots.txt

The /* wildcard was included to clear any cached 404 responses that might have been served before the objects were created. CloudFront invalidations typically propagate within 30–60 seconds, after which fresh content is served from the origin.

Custom Error Response Configuration

During troubleshooting, we discovered that the CloudFront distribution was configured with a custom error response. This is a common pattern for single-page applications or sites that use client-side routing:

  • Error Code: 404 (Not Found)
  • Response Page Path: /index.html (the homepage)
  • HTTP Response Code: 200 (OK)

This configuration meant that when CloudFront received a 404 from the S3 origin (because the object didn't exist yet), it would return the homepage instead. While useful for masking missing content during development, it also masked the fact that our new books object hadn't been deployed. Once we uploaded the actual object and invalidated the cache, CloudFront served the correct content.

Why This Matters: Custom error responses are powerful for SPAs that handle routing client-side, but they can hide deployment issues. When adding new static pages alongside such a configuration, always verify that objects exist in S3 before relying on cache invalidation alone.

Key Decisions

Blocking /books from robots.txt: The receipts page is an internal business tool, not public content. By disallowing it in robots.txt, we prevent it from consuming crawl budget and ensure it won't appear in search results. This is cleaner than relying on authentication alone.

Dual-key S3 Upload: Rather than debugging CloudFront's index document behavior or S3's directory listing configuration, uploading to both books/index.html and books provides explicit, redundant object matching. This is a defensive approach that reduces ambiguity.

Wildcard CloudFront Invalidation: Given the custom error response configuration, invalidating /* ensures that any cached 404 responses are cleared. This is more aggressive than strictly necessary but guarantees a clean slate, especially useful when debugging whether content has actually propagated.

What's Next

The receipts page is now live at quickdumpnow.com/books. The next phase involves:

  • Building out the receipts form interface with backend integration for data submission
  • Connecting to a database or Google Sheets for persistent storage of receipt entries
  • Implementing authentication to restrict access to authorized business users
  • Creating a corresponding port sheet or logging system for charter data (separate initiative)

From an infrastructure perspective, monitor CloudFront's cache hit ratio and S3 request patterns to ensure the configuration remains optimal as the site scales.