SST has rapidly gained traction among TypeScript developers building serverless applications on AWS. Its imperative, code-first approach to infrastructure makes AWS more accessible, particularly for teams with heavy frontend workloads and lean backends. But as your SST application scales from prototype to production, secret management becomes a critical concern that deserves careful consideration.
Understanding SST and Its Infrastructure Model
SST v3 represents a significant evolution in serverless infrastructure tooling. Unlike declarative tools like Terraform or CloudFormation, SST uses imperative TypeScript code to define AWS resources. Built on Pulumi's deployment engine, it provides high-level constructs for common patterns.
For a typical full-stack application, your sst.config.ts might look like this:
export default $config({
app(input) {
return {
name: "my-app",
removal: input?.stage === "production" ? "retain" : "remove",
home: "aws",
};
},
async run() {
// Create a VPC with bastion host and EC2-based NAT (cost-effective alternative to NAT Gateway)
const vpc = new sst.aws.Vpc("Vpc", {
bastion: true,
nat: "ec2",
});
// Create an Aurora Serverless v2 Postgres database inside the VPC
const database = new sst.aws.Aurora("Database", {
engine: "postgres",
vpc,
});
// Create a Lambda function with a Function URL, linked to the database
const api = new sst.aws.Function("ApiFunction", {
handler: "src/api.handler",
vpc,
url: true,
link: [database],
});
// Deploy the frontend as a static site, passing the API URL as an environment variable
const site = new sst.aws.StaticSite("Web", {
path: "frontend",
environment: {
API_URL: api.url,
},
});
},
});
This illustrates SST’s ergonomics: in a small amount of code, you can define networking, a database, an API, and a frontend deployment.
How Does SST Handle Secrets?
SST provides built-in secret management through the sst secret CLI commands and the Secret component.
The workflow is straightforward:
# Set a secret for your current stage npx sst secret set StripeSecretKey sk_test_xxxx # List secrets for the current stage npx sst secret list # Set a secret for production npx sst secret set StripeSecretKey sk_live_xxxx --stage production # Set a fallback value that applies to all stages unless overridden npx sst secret set StripeSecretKey sk_test_xxxx --fallback
The --fallback flag lets you define a default value for a secret that will be used by any stage that hasn't had the secret explicitly set. This is particularly useful for ephemeral stages like PR preview environments, where you don't want to manually configure secrets for each new stage. Fallback values can only be inherited by stages deployed in the same AWS account and region.
In your infrastructure code, you reference secrets using the Secret component:
// infra/storage.ts
export const stripeKey = new sst.Secret("StripeSecretKey");
// infra/api.ts
import { stripeKey } from "./storage";
const api = new sst.aws.Function("ApiFunction", {
handler: "src/api.handler",
link: [stripeKey],
});
Your application code accesses secrets through the Resource object:
import { Resource } from "sst";
import Stripe from "stripe";
const stripe = new Stripe(Resource.StripeSecretKey.value);
Under the hood, SST v3 encrypts secrets and stores them in an S3 bucket within your AWS account. When a function references a secret, SST injects an encrypted payload into the function configuration. At runtime, the SST SDK decrypts the value using IAM permissions associated with the function role. The secret is never stored in plaintext within the infrastructure state. Your infrastructure state is stored separately in S3 as well, with sensitive values encrypted at rest. This approach provides reasonable security for many use cases.
The Limitations of SST's Native Secret Management
As your application matures and your team grows, SST's built-in secret management reveals several constraints:
Stage-Bound Secrets With Limited Hierarchy
SST secrets are stage-specific by default, though the --fallback flag provides a basic inheritance mechanism. You can define a fallback value that any stage will use unless it has an explicitly set value, which works well for ephemeral environments like PR preview stages.
However, this single-level fallback is not a true hierarchical system. You cannot define layered overrides (e.g., a base value, a "development" tier override, and a per-stage override), nor can you share a secret across specific stages without setting it individually on each one. For teams managing many environments with nuanced configuration needs, this flat fallback model still leads to duplication and manual secret management at scale.
No Centralized Secret Visibility
The sst secret list command shows secrets for one stage at a time. There's no dashboard or centralized view of all secrets across all stages and projects. As you manage multiple SST applications, tracking what secrets exist where becomes increasingly difficult.
Limited Access Control and Audit Trail
SST secrets inherit AWS IAM permissions, which provides basic access control but lacks granularity for team-based workflows.
You cannot easily answer questions like:
- Who accessed which secret and when?
- What was the previous value of a rotated secret?
- Which team members have permission to modify production secrets?
While AWS CloudTrail captures infrastructure-level events (such as S3 access or IAM role assumptions), it does not provide secret-level audit visibility. For example, identifying which user accessed a specific logical secret or when its value changed.
No Secret Rotation or Expiration
SST doesn’t include built-in secret rotation workflows. If you need automated rotation, you’ll typically implement it using AWS services (for example, Secrets Manager rotation) or an external secrets platform, and then update the values SST consumes.
Secrets remain valid indefinitely unless manually updated. For compliance requirements like PCI DSS or SOC 2, which mandate regular credential rotation, you must build your own rotation workflows.
5. Manual Secret Synchronization
When secrets change, developers must manually update them across all relevant stages. There's no mechanism to sync a secret update across multiple environments or trigger notifications when secrets are modified.
6. Developer Experience Gaps
The CLI-first approach works well for initial setup but creates friction during active development. Developers need AWS credentials configured locally to set or view secrets. Onboarding new team members requires granting AWS access and documenting which secrets exist and how to configure them.
How Infisical Addresses These Limitations
Infisical provides enterprise-grade secrets management that integrates seamlessly with SST while addressing these operational challenges.
Centralized Secret Management
Infisical provides a single source of truth for all secrets across projects and environments. Your team gets a web dashboard showing every secret, its environments, and modification history. Instead of running CLI commands per stage, you manage secrets in one place with environment-specific overrides automatically applied.
Granular Access Controls and Audit Logging
Infisical implements role-based access control (RBAC) at the project, environment, and secret level. You can grant developers read-only access to development secrets while restricting production secret modifications to senior engineers and automated deployment pipelines.
Every secret access, modification, and deletion generates an audit log entry with timestamp, user identity, and operation details. These logs satisfy compliance requirements and enable security teams to track credential usage patterns.
Automated Secret Rotation
Infisical supports both manual and automated secret rotation workflows. For database credentials, API keys, and other renewable secrets, you can configure rotation schedules that automatically generate new credentials and propagate them to your SST application.
Dynamic Secrets for Ephemeral Workloads
Infisical can issue dynamic credentials for supported backends (e.g., PostgreSQL, MySQL, AWS IAM, etc.), generating short-lived credentials on demand. These credentials include configurable TTLs and are automatically revoked or expire after the lease period. Unlike static secrets, dynamic credentials reduce blast radius by eliminating long-lived passwords entirely.
Seamless SST Integration
Infisical can integrate with SST in a few different ways, depending on your architecture. For static sites and containerized apps, you can use build-time secret injection. For Lambda functions that need up-to-date credentials, you can fetch secrets at runtime.
Team Collaboration Features
Infisical's collaboration features extend beyond secret storage. Teams can:
- Request temporary elevated access to production secrets with approval workflows
- Share secrets with external contractors through time-limited access grants
- Receive notifications when secrets are modified or rotated
- Document secret purposes and ownership within the platform
Implementation Strategy
Migrating from SST's native secrets to Infisical doesn't require a complete rewrite. Start with high-value secrets and expand coverage incrementally:
- Critical Production Secrets: Move production database credentials, API keys for external services, and payment processing secrets to Infisical. These represent the highest risk if compromised.
- Development and Staging Secrets: Extend Infisical to non-production environments. This provides consistency across stages while reducing the operational burden of managing secrets per-stage through the CLI.
- CI/CD Integration: Configure your deployment pipelines to fetch secrets from Infisical. Use dynamic secrets for ephemeral CI/CD credentials to eliminate long-lived credentials in your build process.
- Automated Rotation: Implement rotation schedules for renewable credentials. Start with database passwords and service account keys, then expand to API tokens and certificates.
The Bottom Line
SST's built-in secret management works well for early-stage projects and small teams. The CLI-based workflow feels natural when you're already managing infrastructure through code. But as your application scales, your team grows, and compliance requirements tighten, you'll encounter operational friction that SST's native tooling cannot address.
Infisical provides the missing layer of secrets management maturity: centralized visibility, granular access controls, comprehensive audit logs, and automated rotation. The integration with SST is straightforward, allowing you to preserve SST's excellent developer experience while gaining enterprise-grade secret management capabilities.
The question isn't whether to implement proper secrets management, but when. Will you build these capabilities proactively, or wait until an incident forces your hand? Organizations that treat secrets as critical infrastructure from day one build more secure, more maintainable, and more compliant systems.
Your SST applications deserve the same level of sophistication in secrets management that you've applied to infrastructure as code. Infisical delivers that capability without compromising the velocity that drew you to SST in the first place.
