Virtual tour authoring / AWS
Tour It
I’m rebuilding Tour It’s browser-based authoring workflow and its AWS infrastructure. Authors can turn panorama scenes into connected virtual tours. My work includes the editor, persistent storage, account access, collaboration services, and a release process that protects saved tours while the application changes.
- My part
- I developed the editor and application services, built the AWS infrastructure with CDK, and implemented the deployment and recovery tooling.
- In development
- Staging deployment and release checks have passed. Collaboration testing and recovery rehearsals remain in progress; production promotion is disabled.
Tour It AWS release workflow
- VerifyCodePipeline + CodeBuild
- ProtectPause commits + backups
- DeployPinned source on Amplify
- CheckLive release + tour checks
Building the AWS environment
I defined the infrastructure in TypeScript with AWS CDK, separating persistent data from application delivery and collaboration services. Amplify runs the Next.js application. DynamoDB stores project metadata, permissions, sessions, and release state; private S3 buckets hold panorama images, scene documents, and verified source archives.
The data layer uses encryption, S3 object versioning, DynamoDB point-in-time recovery, and retention settings. Keeping those resources in a separate stack lets me change application delivery while preserving the tables, buckets, and keys that hold saved work.
Saving and serving panoramas
Panorama images upload directly to temporary S3 storage. The application then decodes and validates the image, rechecks the author’s current permissions, and conditionally commits a reference to the accepted object. Uploading bytes alone cannot change a saved scene.
Scene documents and accepted images have immutable keys and retained S3 version IDs. A replacement changes the current reference while keeping the previous object available to backups. Version checks reject stale saves, and durable retry records let a repeated request return its original result.
Media delivery also starts with an authorization check, then redirects to a short-lived signed S3 URL. This keeps large image responses out of the application server. Runtime permissions prevent permanent deletion of accepted media, and browser storage access is limited to the configured application origin.
Identity and AWS permissions
Staging has its own Cognito pool. Signing in establishes an identity; an enrolled member record and project permissions determine what that person can open or change. The application can read membership approval records, while enrollment and approval remain operator actions.
I separated application, build, and worker IAM roles. Client secrets stay in encrypted Systems Manager parameters. Hosted sessions use KMS to encrypt the Cognito token stored server-side, and the browser receives an opaque session cookie. Each role has permissions scoped to its environment and task, including restrictions on destructive storage operations.
Deploying without losing saved work
CodePipeline and CodeBuild verify an exact source revision, run application and infrastructure checks, and exercise the application against local storage services. The verified source is archived in S3 with a version ID, checksum, and release manifest. Amplify builds that archive, and the running application reports its release identity so the controller can check what actually deployed.
I built a Step Functions controller with versioned Lambda workers to coordinate the release. It acquires a release lock and pauses commits for changes that could affect saved data. After a 90-second quiet checkpoint, it creates project and member backups and waits for them to become available before deployment can proceed.
Application infrastructure changes go through reviewed CloudFormation change sets. The release policy rejects deletion or possible replacement of protected stateful resources. After deployment, a dedicated test account checks sign-in, project reads, panorama upload and finalization, and downloaded image bytes. Editing reopens after the checks pass.
The recovery path can redeploy the previous approved application archive and configuration while preserving user saves. Database restoration is a separate operator procedure into new recovery tables. Failure, rollback, and recovery rehearsals still need to establish this behavior under the intended conditions.
Collaboration and background work
API Gateway WebSockets and Lambda carry presence and change notifications. A DynamoDB stream tells the notification service when a project changes. Larger documents and edits travel through authorized HTTPS and private S3 transfers. The browser verifies downloaded bytes before applying an update.
SQS workers copy tour assets in bounded batches, with retry handling and a dead-letter queue. Unacknowledged edits remain in the browser for retry after a disconnect. CloudWatch logs and alerts cover failed releases and queued work, with release-failure notifications sent through SNS.
What has been checked
Hosted staging checks have exercised Cognito sign-in, encrypted sessions, project saves, stale-version rejection, and full-size panorama uploads and downloads with matching checksums. A staging collaboration release completed its backup, infrastructure, deployment, and smoke checks.
Collaboration is enabled in staging. Full testing between two users, including simultaneous edits and reconnect behavior, remains in progress. Automatic builds, automatic releases, and production promotion remain disabled pending the remaining acceptance work. Public publishing and the rebuild’s integration with Infiniscope are also future work.