This message was deleted.

(2) is certainly easier if it will work for all your requirements, so I'd suggest starting with that and then falling back to (3) if you hit some wall (due to potential S3 hosting limitations). Our https://pulumi.io site is actually served from an S3 bucket, using the Pulumi program here (which includes also the Route53, CloudFront, etc. needed for that site's hosting): https://github.com/pulumi/docs/blob/master/infrastructure/index.ts We don't use redirect rules for that site, but they area available via the Pulumi API. See

routingRules

at https://github.com/pulumi/pulumi-aws/blob/master/sdk/nodejs/s3/bucket.ts#L109 and the format of routing rules here: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-s3-websiteconfiguration-routingrules.html

@miniature-potato-84713 I would actually advise always going with the managed option if you don’t need the flexibility of the orchestrator.

Neat, thanks @white-balloon-205 for the links! I’ll get to it this week/end/ish. Before Christmas for sure 😄

Yes - that's right!

…and I can tie the Github actions into it as well, so that a push to

master

will update the S3 content objects?

Yep. You can do something simple and already available like Travis - that’s what the docs site I linked above does - you can see how it’s Travis job deploys to the corresponding stack for some branches (like

master

and

production

). If you have access to Actions, you could do that too in a similar way.

@white-balloon-205, getting started on this now.

pulumi new

is probably best, but the

<https://github.com/pulumi/docs/tree/master/infrastructure>

would be a

aws-typescript

template?