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

What Was Done

We deployed a new receipt management landing page to https://quickdumpnow.com/books for a trailer rental business. The deployment involved creating a new single-page application, configuring S3 object paths for pretty URLs, updating robots.txt exclusions, and invalidating CloudFront distribution caches to ensure the new endpoint was publicly accessible within 30–60 seconds.

Technical Details: File Structure and Deployment

The quickdumpnow.com codebase is organized in the following local structure:

/Users/cb/Documents/repos/sites/quickdumpnow.com/
├── books/
│   └── index.html
└── robots.txt

The books/index.html file was created as a new landing page for receipt uploads. The page uses a simple, clean design that matches the existing quickdumpnow.com aesthetic and serves as the entry point for the trailer rental business's receipt management system.

To enable pretty URLs (so users visit /books instead of /books/index.html), we uploaded the same HTML content to two S3 keys:

• s3://quickdumpnow.com/books/index.html — the traditional nested key structure
• s3://quickdumpnow.com/books — a bare key without the index.html suffix, allowing CloudFront to serve the content at the clean URL

Both objects were uploaded with the same content type (text/html; charset=utf-8) and cache headers to ensure consistency.

Robots.txt and SEO Exclusion

The robots.txt file was updated to explicitly exclude the books path from search engine indexing:

User-agent: *
Disallow: /books

This exclusion was necessary because the receipt management system is intended as an internal tool for the business owner, not a public-facing resource. By blocking search engines at the robots.txt level, we prevent indexed pages and reduce unnecessary crawl traffic.

Infrastructure: CloudFront Configuration and Cache Invalidation

The quickdumpnow.com distribution uses CloudFront as a CDN edge layer, with S3 as the origin. A critical detail discovered during deployment was that the CloudFront distribution has a custom error response configured:

• Error Code: 404 (Not Found)
• Response Page Path: / (homepage)
• HTTP Response Code: 200

This custom error response meant that before we uploaded the books page, any request to /books would return a 404 from S3, triggering CloudFront's error handler, which then served the homepage with a 200 status code. This is a common pattern for single-page applications (SPAs), but it requires careful management when adding new static routes.

After uploading the books page objects to S3, we invalidated the CloudFront cache for the following paths:

• /books — the bare path
• /books/* — any nested paths under books
• /robots.txt — the updated robots.txt file

CloudFront cache invalidations are processed asynchronously and typically propagate within 30–60 seconds across all edge locations. The invalidation request ID can be tracked in the CloudFront console to monitor status.

Key Decisions and Rationale

Why two S3 keys for the same content? CloudFront doesn't have built-in directory index behavior like a traditional web server. By uploading to both books/index.html and books, we ensure that requests to either path are served correctly. The bare books key allows users to visit /books (without a trailing slash) and receive the HTML content directly.

Why update robots.txt first? We updated robots.txt before the cache invalidation to ensure that when search engine crawlers hit the new page (even accidentally), they respect the Disallow: /books rule. This prevents the brief window where the page might be crawlable before we formally excluded it.

Why not use S3 static website hosting? The quickdumpnow.com domain uses CloudFront as the primary delivery mechanism, with S3 configured only as an origin (not as a static website). This setup provides better control over caching, HTTPS termination, and security headers. Adding index document logic at the S3 level would require switching to static website hosting, which would complicate the CloudFront origin configuration.

Why be cautious of custom 404 error responses? Custom error responses can mask real issues. In this case, the 404-to-homepage redirect meant that any typo or missing page still returned 200 OK. This is acceptable for an SPA but requires that new static routes be explicitly uploaded to S3; otherwise, they silently redirect to the homepage, creating confusion during development.

What's Next

The receipt management system is now live at https://quickdumpnow.com/books. The next phase involves:

• Implementing a backend API to handle receipt uploads and storage (likely using AWS Lambda and S3)
• Adding authentication to restrict access to the business owner
• Integrating with the trailer rental business's accounting system
• Monitoring CloudFront access logs to track traffic patterns and performance

The current deployment provides a solid foundation with proper caching, SEO exclusion, and CDN acceleration. All infrastructure decisions prioritize performance, security, and maintainability for future feature additions.