Bot releases are visible (Hide)
Published by github-actions[bot] about 2 years ago
Published by github-actions[bot] over 2 years ago
import * as rds from "aws-cdk-lib/aws-rds";
import * as secretsManager from "aws-cdk-lib/aws-secretsmanager";
new RDS(stack, "Database", {
engine: "postgresql10.14",
defaultDatabaseName: "acme",
cdk: {
cluster: rds.ServerlessCluster.fromServerlessClusterAttributes(stack, "ICluster", {
clusterIdentifier: "my-existing-cluster",
}),
secret: secretsManager.Secret.fromSecretAttributes(stack, "ISecret", {
secretPartialArn: "arn:aws:secretsmanager:us-east-1:123456789012:secret:my-secret",
}),
},
});
Read more about importing existing Serverless v1 clusters here - https://docs.sst.dev/constructs/RDS#import-existing-rds-serverless-v1-cluster
Update using:
$ npx sst update v1.6.0
$ yarn sst update v1.6.0
Published by github-actions[bot] over 2 years ago
RemixSite
It lets you deploy Remix apps to AWS with ease!
new RemixSite(stack, "Site", {
path: "my-remix-app/"
});
Similar to other SST Site constructs, you can configure:
process.env.API_URL
Learn more https://docs.sst.dev/constructs/RemixSite
RemixSite
offers two deployment modes: Single-Region and Edge. Single-Region is the default behavior, and likely the better choice for your setup. If you want to deploy to Edge in spite of watching the Ending edge function hype video, enable the edge
flag, and the Remix app server will be deployed to Lambda@Edge.
new RemixSite(stack, "Site", {
path: "my-remix-app/",
edge: true,
});
We will be hosting a live event on July 19th at 9am PDT. We'll be diving into the details of RemixSite
, and answering some questions from the community.
https://www.youtube.com/watch?v=ZBbRZTTCwvU
Set a reminder!
Finally, big hugs to @ctrlplusb. Sean's awesome PR taught me all about Remix; how the server is bundled; and how to wrap the bundle into a Lambda function - https://github.com/serverless-stack/sst/pull/1800
30ca1ca82
Thanks @ctrlplusb! - Add RemixSite constructUpdate using:
$ npx sst update v1.4.0
$ yarn sst update v1.4.0
Published by github-actions[bot] over 2 years ago
d3c30eb5b
- Auth: make "attachPermissionsToAuthUsers" take scope to control stack dependencies when referening resources from another stackAuth.attachPermissionsForAuthUsers()
and Auth.attachPermissionsForUnauthUsers()
now take a scope as the first argument. Previously, when attaching permissions, the IAM policies were always added to Auth
's stack. This means that when attaching permissions from another stack, it will create a stack dependency. In some cases, this can lead to a cyclic dependency. For example:
// AuthStack.ts
const auth = new Auth(stack, "auth");
return { auth };
// ApiStack.ts
const { auth } = use(AuthStack);
const api = new Api(stack, "api", {
defaults: {
function: {
environment: {
// This causes ApiStack depend on AuthStack
USER_POOL_ID: auth.userPooldId,
}
}
}
});
// This causes AuthStack depend on ApiStack
auth.attachPermissionsForAuthUsers([api]);
Instead, if the IAM policies were added to the ApiStack, AuthStack would no longer depend on ApiStack, breaking the cyclic dependency. You can do that:
auth.attachPermissionsForAuthUsers(stack, permissions)
And if you want to preserve the previous behavior:
// Change
auth.attachPermissionsForAuthUsers([api]);
// to
auth.attachPermissionsForAuthUsers(auth, [api]);
430549cc8
- sst console: fix undefined port in the console linkUpdate using:
$ npx sst update v1.3.0
$ yarn sst update v1.3.0