Engineering guides / Angular applications and AWS infrastructure
By Arte Soft engineering · 24 October 2026
S3 and CloudFront deployment with a recoverable release
Uploading a website to S3 is only one part of a public release. Visitors reach a distribution with its own cache, certificates and routing behavior. A dependable S3 and CloudFront deployment makes those layers agree, including when a page does not exist or an old asset remains cached. The result should be a release someone can inspect and reverse.
Decide what is actually static
A prerendered service page, a versioned JavaScript file and an authenticated API response have different delivery requirements. Keep dynamic or private data outside an indiscriminate static cache. Define whether each public route corresponds to a generated HTML object and how trailing slashes resolve. A blanket fallback that returns the home page for every missing URL can disguise broken links and produce misleading status codes. List the routes and response behavior before configuring error handling. This is particularly important when a site mixes content pages with a browser application that genuinely needs a controlled fallback.
Set access and caching deliberately
Choose the origin configuration appropriate to the deployment, including the documented distinction between an S3 bucket origin and a website endpoint. Restrict origin access where supported rather than making private implementation files public for convenience. Give versioned assets long-lived cache policies while ensuring HTML can change promptly. Configure content types correctly for images, fonts and video. Document certificate ownership and domain changes alongside infrastructure configuration. A cache invalidation is not a substitute for understanding which objects should be immutable. The release plan should explain what changes on each deployment and what existing content must be preserved.
Verify the public distribution
Deliver the build output, deployment procedure, cache rules and rollback instructions. Acceptance includes fetching a representative page, a deep link, a missing address and a versioned asset through the public domain. Inspect status, content type and actual body rather than relying on an upload success message. Confirm that an updated legal page reaches the edge after the agreed propagation process. Keep a release manifest or equivalent record connecting the source revision with deployed objects. If media lives in a separate bucket, verify its references without accidentally deleting shared originals during a routine website synchronization.
Use deployment permissions that fit the publisher’s job rather than a general administrator credential. A release routine should not require the ability to delete unrelated databases or change billing settings merely to replace public HTML and versioned assets.
Keep operations proportionate
A small static site can have a simple release process, but simplicity should not mean manual secrets, undocumented exclusions or irreversible object deletion. Decide who can publish and how another person can recover the last good revision. Arte Soft’s own public product websites provide useful examples of media-heavy product presentation; they are not a guarantee that your cache policy should match ours. Bring your route structure, current hosting and publication frequency. We can scope a deployment that preserves content ownership, exposes mistakes clearly and supports an ordinary update without rebuilding an unnecessarily complex platform.
Relevant Arte Soft work
Reel Screen Recorder — our own product is our own product or engineering project. It provides context for the work we discuss here; it is not a claim of identical results for every client deployment.
Sources and further reading
Need help with Static site cloud deployment?
Send the current app, system or brief, the behaviour you need and your constraints. We can agree a discovery, implementation or repair scope with concrete acceptance criteria.
Discuss this with Arte Soft