fix(infra): JARL1188 — restore the /ssr/* behaviour on the repointed VPC origin

[randomdevpete]

Restores the /ssr/* behaviour on the distribution, pointing at the VPC origin that now addresses the EC2 instance directly — uncached (CACHING_DISABLED), whole viewer request forwarded (ALL_VIEWER), GET/HEAD/OPTIONS, no directory-index function. All three synthesized templates come out byte-identical to the ones from before the behaviour was detached.

That completes the cutover: the origin is repointed, the load balancer is gone, and /ssr/* leaves S3 again.

Stack order

ssr.addDependency(staticSite) is removed, and keeping it was not an option: JarlStaticSite's template references the origin again, so the explicit edge now fails synth with Adding this dependency (JarlStaticSite -> JarlSsr/SsrInstance/Resource.PrivateDnsName) would create a cyclic reference. The natural edge is back and points the other way — from cdk.out/manifest.json:

JarlStaticSite -> dependencies: ['JarlSsr', 'JarlDomain', 'JarlStaticSite.assets']
JarlSsr -> dependencies: ['JarlSsr.assets']

So cdk deploy --all runs JarlDomain and JarlSsr first and JarlStaticSite last — the order infra/README.md documents, which the detach deploy had inverted.

Will the post-deploy /ssr/ 200 check pass

I believe so, and the three preconditions hold independently of this diff:

• Serving on 3000.packages/docs/src/prod-server.ts handles /ssr/ by rendering /, a route that matches, so it returns 200 rather than the 404 an unmatched path gets. The roll step waits for /healthz on the instance before it curls the distribution, so a server that failed to start fails earlier and more legibly.
• Security group. The rule admitting CloudFront-VPCOrigins-Service-SG on 3000 went out with the origin repoint and is live; this change does not touch it.
• Propagation. Not a race, and not by luck. CloudFormation does not report an AWS::CloudFront::Distribution update complete until the distribution reaches Deployed, so cdk deploy --all has already blocked on edge propagation before the workflow moves on. Two further steps run in between, and the check itself retries 24 times at 5s.

The one thing that could have raced is stale negative caching — /ssr/ currently serves the distribution-wide 404 with a 5 minute TTL. Publish site content invalidates /* immediately beforehand, and the restored behaviour is CACHING_DISABLED regardless, so an edge holding that 404 will not still be serving it inside the check's 2 minute budget.

The residual risk is unrelated to reattaching: MachineImage.latestAmazonLinux2023() re-resolves every deploy, so a new AMI replaces the instance and ssm send-command can arrive before the SSM agent has registered. That is the hazard infra/README.md already sets out, not one this introduces.

Scaffolding removed

The mid-cutover blockquote and the comment beside the VpcOrigin are gone. infra/README.md keeps the two-deploy constraint, rewritten as a property of the origin rather than a note about this particular cutover, since anyone repointing it again meets the same 409.

SsrPathPattern's description needed no edit — "Distribution paths served by the SSR instance rather than S3" is exactly the sentence that was stale during the window and is true again now. The traffic-path prose already read viewer → CloudFront → VPC origin → instance:3000.

Checks: tsc --noEmit -p infra/tsconfig.json, oxfmt --check, oxlint and cdk synth under env -i with an empty HOME all pass.

[randomdevpete]

Restores the /ssr/* behaviour on the distribution, pointing at the VPC origin that now addresses the EC2 instance directly — uncached (CACHING_DISABLED), whole viewer request forwarded (ALL_VIEWER), GET/HEAD/OPTIONS, no directory-index function. All three synthesized templates come out byte-identical to the ones from before the behaviour was detached.

That completes the cutover: the origin is repointed, the load balancer is gone, and /ssr/* leaves S3 again.

Stack order

ssr.addDependency(staticSite) is removed, and keeping it was not an option: JarlStaticSite's template references the origin again, so the explicit edge now fails synth with Adding this dependency (JarlStaticSite -> JarlSsr/SsrInstance/Resource.PrivateDnsName) would create a cyclic reference. The natural edge is back and points the other way — from cdk.out/manifest.json:

JarlStaticSite -> dependencies: ['JarlSsr', 'JarlDomain', 'JarlStaticSite.assets']
JarlSsr -> dependencies: ['JarlSsr.assets']

So cdk deploy --all runs JarlDomain and JarlSsr first and JarlStaticSite last — the order infra/README.md documents, which the detach deploy had inverted.

Will the post-deploy /ssr/ 200 check pass

I believe so, and the three preconditions hold independently of this diff:

• Serving on 3000.packages/docs/src/prod-server.ts handles /ssr/ by rendering /, a route that matches, so it returns 200 rather than the 404 an unmatched path gets. The roll step waits for /healthz on the instance before it curls the distribution, so a server that failed to start fails earlier and more legibly.
• Security group. The rule admitting CloudFront-VPCOrigins-Service-SG on 3000 went out with the origin repoint and is live; this change does not touch it.
• Propagation. Not a race, and not by luck. CloudFormation does not report an AWS::CloudFront::Distribution update complete until the distribution reaches Deployed, so cdk deploy --all has already blocked on edge propagation before the workflow moves on. Two further steps run in between, and the check itself retries 24 times at 5s.

The one thing that could have raced is stale negative caching — /ssr/ currently serves the distribution-wide 404 with a 5 minute TTL. Publish site content invalidates /* immediately beforehand, and the restored behaviour is CACHING_DISABLED regardless, so an edge holding that 404 will not still be serving it inside the check's 2 minute budget.

The residual risk is unrelated to reattaching: MachineImage.latestAmazonLinux2023() re-resolves every deploy, so a new AMI replaces the instance and ssm send-command can arrive before the SSM agent has registered. That is the hazard infra/README.md already sets out, not one this introduces.

Scaffolding removed

The mid-cutover blockquote and the comment beside the VpcOrigin are gone. infra/README.md keeps the two-deploy constraint, rewritten as a property of the origin rather than a note about this particular cutover, since anyone repointing it again meets the same 409.

SsrPathPattern's description needed no edit — "Distribution paths served by the SSR instance rather than S3" is exactly the sentence that was stale during the window and is true again now. The traffic-path prose already read viewer → CloudFront → VPC origin → instance:3000.

Checks: tsc --noEmit -p infra/tsconfig.json, oxfmt --check, oxlint and cdk synth under env -i with an empty HOME all pass.

[randomdevpete]

Restores the /ssr/* behaviour on the distribution, pointing at the VPC origin that now addresses the EC2 instance directly — uncached (CACHING_DISABLED), whole viewer request forwarded (ALL_VIEWER), GET/HEAD/OPTIONS, no directory-index function. All three synthesized templates come out byte-identical to the ones from before the behaviour was detached.

That completes the cutover: the origin is repointed, the load balancer is gone, and /ssr/* leaves S3 again.

Stack order

ssr.addDependency(staticSite) is removed, and keeping it was not an option: JarlStaticSite's template references the origin again, so the explicit edge now fails synth with Adding this dependency (JarlStaticSite -> JarlSsr/SsrInstance/Resource.PrivateDnsName) would create a cyclic reference. The natural edge is back and points the other way — from cdk.out/manifest.json:

JarlStaticSite -> dependencies: ['JarlSsr', 'JarlDomain', 'JarlStaticSite.assets']
JarlSsr -> dependencies: ['JarlSsr.assets']

So cdk deploy --all runs JarlDomain and JarlSsr first and JarlStaticSite last — the order infra/README.md documents, which the detach deploy had inverted.

Will the post-deploy /ssr/ 200 check pass

I believe so, and the three preconditions hold independently of this diff:

• Serving on 3000.packages/docs/src/prod-server.ts handles /ssr/ by rendering /, a route that matches, so it returns 200 rather than the 404 an unmatched path gets. The roll step waits for /healthz on the instance before it curls the distribution, so a server that failed to start fails earlier and more legibly.
• Security group. The rule admitting CloudFront-VPCOrigins-Service-SG on 3000 went out with the origin repoint and is live; this change does not touch it.
• Propagation. Not a race, and not by luck. CloudFormation does not report an AWS::CloudFront::Distribution update complete until the distribution reaches Deployed, so cdk deploy --all has already blocked on edge propagation before the workflow moves on. Two further steps run in between, and the check itself retries 24 times at 5s.

The one thing that could have raced is stale negative caching — /ssr/ currently serves the distribution-wide 404 with a 5 minute TTL. Publish site content invalidates /* immediately beforehand, and the restored behaviour is CACHING_DISABLED regardless, so an edge holding that 404 will not still be serving it inside the check's 2 minute budget.

The residual risk is unrelated to reattaching: MachineImage.latestAmazonLinux2023() re-resolves every deploy, so a new AMI replaces the instance and ssm send-command can arrive before the SSM agent has registered. That is the hazard infra/README.md already sets out, not one this introduces.

Scaffolding removed

The mid-cutover blockquote and the comment beside the VpcOrigin are gone. infra/README.md keeps the two-deploy constraint, rewritten as a property of the origin rather than a note about this particular cutover, since anyone repointing it again meets the same 409.

SsrPathPattern's description needed no edit — "Distribution paths served by the SSR instance rather than S3" is exactly the sentence that was stale during the window and is true again now. The traffic-path prose already read viewer → CloudFront → VPC origin → instance:3000.

Checks: tsc --noEmit -p infra/tsconfig.json, oxfmt --check, oxlint and cdk synth under env -i with an empty HOME all pass.

[randomdevpete]

Restores the /ssr/* behaviour on the distribution, pointing at the VPC origin that now addresses the EC2 instance directly — uncached (CACHING_DISABLED), whole viewer request forwarded (ALL_VIEWER), GET/HEAD/OPTIONS, no directory-index function. All three synthesized templates come out byte-identical to the ones from before the behaviour was detached.

That completes the cutover: the origin is repointed, the load balancer is gone, and /ssr/* leaves S3 again.

Stack order

ssr.addDependency(staticSite) is removed, and keeping it was not an option: JarlStaticSite's template references the origin again, so the explicit edge now fails synth with Adding this dependency (JarlStaticSite -> JarlSsr/SsrInstance/Resource.PrivateDnsName) would create a cyclic reference. The natural edge is back and points the other way — from cdk.out/manifest.json:

JarlStaticSite -> dependencies: ['JarlSsr', 'JarlDomain', 'JarlStaticSite.assets']
JarlSsr -> dependencies: ['JarlSsr.assets']

So cdk deploy --all runs JarlDomain and JarlSsr first and JarlStaticSite last — the order infra/README.md documents, which the detach deploy had inverted.

Will the post-deploy /ssr/ 200 check pass

I believe so, and the three preconditions hold independently of this diff:

• Serving on 3000.packages/docs/src/prod-server.ts handles /ssr/ by rendering /, a route that matches, so it returns 200 rather than the 404 an unmatched path gets. The roll step waits for /healthz on the instance before it curls the distribution, so a server that failed to start fails earlier and more legibly.
• Security group. The rule admitting CloudFront-VPCOrigins-Service-SG on 3000 went out with the origin repoint and is live; this change does not touch it.
• Propagation. Not a race, and not by luck. CloudFormation does not report an AWS::CloudFront::Distribution update complete until the distribution reaches Deployed, so cdk deploy --all has already blocked on edge propagation before the workflow moves on. Two further steps run in between, and the check itself retries 24 times at 5s.

The one thing that could have raced is stale negative caching — /ssr/ currently serves the distribution-wide 404 with a 5 minute TTL. Publish site content invalidates /* immediately beforehand, and the restored behaviour is CACHING_DISABLED regardless, so an edge holding that 404 will not still be serving it inside the check's 2 minute budget.

The residual risk is unrelated to reattaching: MachineImage.latestAmazonLinux2023() re-resolves every deploy, so a new AMI replaces the instance and ssm send-command can arrive before the SSM agent has registered. That is the hazard infra/README.md already sets out, not one this introduces.

Scaffolding removed

The mid-cutover blockquote and the comment beside the VpcOrigin are gone. infra/README.md keeps the two-deploy constraint, rewritten as a property of the origin rather than a note about this particular cutover, since anyone repointing it again meets the same 409.

SsrPathPattern's description needed no edit — "Distribution paths served by the SSR instance rather than S3" is exactly the sentence that was stale during the window and is true again now. The traffic-path prose already read viewer → CloudFront → VPC origin → instance:3000.

Checks: tsc --noEmit -p infra/tsconfig.json, oxfmt --check, oxlint and cdk synth under env -i with an empty HOME all pass.

[randomdevpete]

Restores the /ssr/* behaviour on the distribution, pointing at the VPC origin that now addresses the EC2 instance directly — uncached (CACHING_DISABLED), whole viewer request forwarded (ALL_VIEWER), GET/HEAD/OPTIONS, no directory-index function. All three synthesized templates come out byte-identical to the ones from before the behaviour was detached.

That completes the cutover: the origin is repointed, the load balancer is gone, and /ssr/* leaves S3 again.

Stack order

ssr.addDependency(staticSite) is removed, and keeping it was not an option: JarlStaticSite's template references the origin again, so the explicit edge now fails synth with Adding this dependency (JarlStaticSite -> JarlSsr/SsrInstance/Resource.PrivateDnsName) would create a cyclic reference. The natural edge is back and points the other way — from cdk.out/manifest.json:

JarlStaticSite -> dependencies: ['JarlSsr', 'JarlDomain', 'JarlStaticSite.assets']
JarlSsr -> dependencies: ['JarlSsr.assets']

So cdk deploy --all runs JarlDomain and JarlSsr first and JarlStaticSite last — the order infra/README.md documents, which the detach deploy had inverted.

Will the post-deploy /ssr/ 200 check pass

I believe so, and the three preconditions hold independently of this diff:

• Serving on 3000.packages/docs/src/prod-server.ts handles /ssr/ by rendering /, a route that matches, so it returns 200 rather than the 404 an unmatched path gets. The roll step waits for /healthz on the instance before it curls the distribution, so a server that failed to start fails earlier and more legibly.
• Security group. The rule admitting CloudFront-VPCOrigins-Service-SG on 3000 went out with the origin repoint and is live; this change does not touch it.
• Propagation. Not a race, and not by luck. CloudFormation does not report an AWS::CloudFront::Distribution update complete until the distribution reaches Deployed, so cdk deploy --all has already blocked on edge propagation before the workflow moves on. Two further steps run in between, and the check itself retries 24 times at 5s.

The one thing that could have raced is stale negative caching — /ssr/ currently serves the distribution-wide 404 with a 5 minute TTL. Publish site content invalidates /* immediately beforehand, and the restored behaviour is CACHING_DISABLED regardless, so an edge holding that 404 will not still be serving it inside the check's 2 minute budget.

The residual risk is unrelated to reattaching: MachineImage.latestAmazonLinux2023() re-resolves every deploy, so a new AMI replaces the instance and ssm send-command can arrive before the SSM agent has registered. That is the hazard infra/README.md already sets out, not one this introduces.

Scaffolding removed

The mid-cutover blockquote and the comment beside the VpcOrigin are gone. infra/README.md keeps the two-deploy constraint, rewritten as a property of the origin rather than a note about this particular cutover, since anyone repointing it again meets the same 409.

SsrPathPattern's description needed no edit — "Distribution paths served by the SSR instance rather than S3" is exactly the sentence that was stale during the window and is true again now. The traffic-path prose already read viewer → CloudFront → VPC origin → instance:3000.

Checks: tsc --noEmit -p infra/tsconfig.json, oxfmt --check, oxlint and cdk synth under env -i with an empty HOME all pass.

[randomdevpete]

Restores the /ssr/* behaviour on the distribution, pointing at the VPC origin that now addresses the EC2 instance directly — uncached (CACHING_DISABLED), whole viewer request forwarded (ALL_VIEWER), GET/HEAD/OPTIONS, no directory-index function. All three synthesized templates come out byte-identical to the ones from before the behaviour was detached.

That completes the cutover: the origin is repointed, the load balancer is gone, and /ssr/* leaves S3 again.

Stack order

ssr.addDependency(staticSite) is removed, and keeping it was not an option: JarlStaticSite's template references the origin again, so the explicit edge now fails synth with Adding this dependency (JarlStaticSite -> JarlSsr/SsrInstance/Resource.PrivateDnsName) would create a cyclic reference. The natural edge is back and points the other way — from cdk.out/manifest.json:

JarlStaticSite -> dependencies: ['JarlSsr', 'JarlDomain', 'JarlStaticSite.assets']
JarlSsr -> dependencies: ['JarlSsr.assets']

So cdk deploy --all runs JarlDomain and JarlSsr first and JarlStaticSite last — the order infra/README.md documents, which the detach deploy had inverted.

Will the post-deploy /ssr/ 200 check pass

I believe so, and the three preconditions hold independently of this diff:

• Serving on 3000.packages/docs/src/prod-server.ts handles /ssr/ by rendering /, a route that matches, so it returns 200 rather than the 404 an unmatched path gets. The roll step waits for /healthz on the instance before it curls the distribution, so a server that failed to start fails earlier and more legibly.
• Security group. The rule admitting CloudFront-VPCOrigins-Service-SG on 3000 went out with the origin repoint and is live; this change does not touch it.
• Propagation. Not a race, and not by luck. CloudFormation does not report an AWS::CloudFront::Distribution update complete until the distribution reaches Deployed, so cdk deploy --all has already blocked on edge propagation before the workflow moves on. Two further steps run in between, and the check itself retries 24 times at 5s.

The one thing that could have raced is stale negative caching — /ssr/ currently serves the distribution-wide 404 with a 5 minute TTL. Publish site content invalidates /* immediately beforehand, and the restored behaviour is CACHING_DISABLED regardless, so an edge holding that 404 will not still be serving it inside the check's 2 minute budget.

The residual risk is unrelated to reattaching: MachineImage.latestAmazonLinux2023() re-resolves every deploy, so a new AMI replaces the instance and ssm send-command can arrive before the SSM agent has registered. That is the hazard infra/README.md already sets out, not one this introduces.

Scaffolding removed

The mid-cutover blockquote and the comment beside the VpcOrigin are gone. infra/README.md keeps the two-deploy constraint, rewritten as a property of the origin rather than a note about this particular cutover, since anyone repointing it again meets the same 409.

SsrPathPattern's description needed no edit — "Distribution paths served by the SSR instance rather than S3" is exactly the sentence that was stale during the window and is true again now. The traffic-path prose already read viewer → CloudFront → VPC origin → instance:3000.

Checks: tsc --noEmit -p infra/tsconfig.json, oxfmt --check, oxlint and cdk synth under env -i with an empty HOME all pass.

[randomdevpete]

Restores the /ssr/* behaviour on the distribution, pointing at the VPC origin that now addresses the EC2 instance directly — uncached (CACHING_DISABLED), whole viewer request forwarded (ALL_VIEWER), GET/HEAD/OPTIONS, no directory-index function. All three synthesized templates come out byte-identical to the ones from before the behaviour was detached.

That completes the cutover: the origin is repointed, the load balancer is gone, and /ssr/* leaves S3 again.

Stack order

ssr.addDependency(staticSite) is removed, and keeping it was not an option: JarlStaticSite's template references the origin again, so the explicit edge now fails synth with Adding this dependency (JarlStaticSite -> JarlSsr/SsrInstance/Resource.PrivateDnsName) would create a cyclic reference. The natural edge is back and points the other way — from cdk.out/manifest.json:

JarlStaticSite -> dependencies: ['JarlSsr', 'JarlDomain', 'JarlStaticSite.assets']
JarlSsr -> dependencies: ['JarlSsr.assets']

So cdk deploy --all runs JarlDomain and JarlSsr first and JarlStaticSite last — the order infra/README.md documents, which the detach deploy had inverted.

Will the post-deploy /ssr/ 200 check pass

I believe so, and the three preconditions hold independently of this diff:

• Serving on 3000.packages/docs/src/prod-server.ts handles /ssr/ by rendering /, a route that matches, so it returns 200 rather than the 404 an unmatched path gets. The roll step waits for /healthz on the instance before it curls the distribution, so a server that failed to start fails earlier and more legibly.
• Security group. The rule admitting CloudFront-VPCOrigins-Service-SG on 3000 went out with the origin repoint and is live; this change does not touch it.
• Propagation. Not a race, and not by luck. CloudFormation does not report an AWS::CloudFront::Distribution update complete until the distribution reaches Deployed, so cdk deploy --all has already blocked on edge propagation before the workflow moves on. Two further steps run in between, and the check itself retries 24 times at 5s.

The one thing that could have raced is stale negative caching — /ssr/ currently serves the distribution-wide 404 with a 5 minute TTL. Publish site content invalidates /* immediately beforehand, and the restored behaviour is CACHING_DISABLED regardless, so an edge holding that 404 will not still be serving it inside the check's 2 minute budget.

The residual risk is unrelated to reattaching: MachineImage.latestAmazonLinux2023() re-resolves every deploy, so a new AMI replaces the instance and ssm send-command can arrive before the SSM agent has registered. That is the hazard infra/README.md already sets out, not one this introduces.

Scaffolding removed

The mid-cutover blockquote and the comment beside the VpcOrigin are gone. infra/README.md keeps the two-deploy constraint, rewritten as a property of the origin rather than a note about this particular cutover, since anyone repointing it again meets the same 409.

SsrPathPattern's description needed no edit — "Distribution paths served by the SSR instance rather than S3" is exactly the sentence that was stale during the window and is true again now. The traffic-path prose already read viewer → CloudFront → VPC origin → instance:3000.

Checks: tsc --noEmit -p infra/tsconfig.json, oxfmt --check, oxlint and cdk synth under env -i with an empty HOME all pass.

[randomdevpete]

Restores the /ssr/* behaviour on the distribution, pointing at the VPC origin that now addresses the EC2 instance directly — uncached (CACHING_DISABLED), whole viewer request forwarded (ALL_VIEWER), GET/HEAD/OPTIONS, no directory-index function. All three synthesized templates come out byte-identical to the ones from before the behaviour was detached.

That completes the cutover: the origin is repointed, the load balancer is gone, and /ssr/* leaves S3 again.

Stack order

ssr.addDependency(staticSite) is removed, and keeping it was not an option: JarlStaticSite's template references the origin again, so the explicit edge now fails synth with Adding this dependency (JarlStaticSite -> JarlSsr/SsrInstance/Resource.PrivateDnsName) would create a cyclic reference. The natural edge is back and points the other way — from cdk.out/manifest.json:

JarlStaticSite -> dependencies: ['JarlSsr', 'JarlDomain', 'JarlStaticSite.assets']
JarlSsr -> dependencies: ['JarlSsr.assets']

So cdk deploy --all runs JarlDomain and JarlSsr first and JarlStaticSite last — the order infra/README.md documents, which the detach deploy had inverted.

Will the post-deploy /ssr/ 200 check pass

I believe so, and the three preconditions hold independently of this diff:

• Serving on 3000.packages/docs/src/prod-server.ts handles /ssr/ by rendering /, a route that matches, so it returns 200 rather than the 404 an unmatched path gets. The roll step waits for /healthz on the instance before it curls the distribution, so a server that failed to start fails earlier and more legibly.
• Security group. The rule admitting CloudFront-VPCOrigins-Service-SG on 3000 went out with the origin repoint and is live; this change does not touch it.
• Propagation. Not a race, and not by luck. CloudFormation does not report an AWS::CloudFront::Distribution update complete until the distribution reaches Deployed, so cdk deploy --all has already blocked on edge propagation before the workflow moves on. Two further steps run in between, and the check itself retries 24 times at 5s.

The one thing that could have raced is stale negative caching — /ssr/ currently serves the distribution-wide 404 with a 5 minute TTL. Publish site content invalidates /* immediately beforehand, and the restored behaviour is CACHING_DISABLED regardless, so an edge holding that 404 will not still be serving it inside the check's 2 minute budget.

The residual risk is unrelated to reattaching: MachineImage.latestAmazonLinux2023() re-resolves every deploy, so a new AMI replaces the instance and ssm send-command can arrive before the SSM agent has registered. That is the hazard infra/README.md already sets out, not one this introduces.

Scaffolding removed

The mid-cutover blockquote and the comment beside the VpcOrigin are gone. infra/README.md keeps the two-deploy constraint, rewritten as a property of the origin rather than a note about this particular cutover, since anyone repointing it again meets the same 409.

SsrPathPattern's description needed no edit — "Distribution paths served by the SSR instance rather than S3" is exactly the sentence that was stale during the window and is true again now. The traffic-path prose already read viewer → CloudFront → VPC origin → instance:3000.

Checks: tsc --noEmit -p infra/tsconfig.json, oxfmt --check, oxlint and cdk synth under env -i with an empty HOME all pass.