Every Lightpress service reads its configuration from environment variables at startup. During local development these values live in aDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/reds-skywalker/Lightpress/llms.txt
Use this file to discover all available pages before exploring further.
.env file at the project root (excluded from version control via .gitignore). In production, you supply them through your deployment pipeline — typically as CodeBuild environment variables or AWS Systems Manager Parameter Store entries.
Never commit
.env to version control. Use .env.example to document required variables with safe placeholder values so that other developers know what to configure.Application settings
These variables control the runtime behavior common to all Node.js services in Lightpress.Runtime environment. Affects logging verbosity, error detail in responses, and performance optimizations. Accepted values:
development, test, production.The port each service listens on. When running multiple services locally, set a different port per service (e.g.
3001, 3002) to avoid conflicts. In Docker Compose this is handled by port mapping, so you can leave the default.Minimum log severity to emit. Accepted values:
error, warn, info, http, debug. Set to debug locally for verbose output; use warn or error in production to reduce log volume and cost.A short identifier for the running service (e.g.
auth-service, billing-service). Included in structured log output to make it easy to filter logs in CloudWatch.Database
Lightpress uses a relational database for persistent state. Configure the connection using individual components or a single connection string.Hostname or IP address of the database server. Locally this is typically
localhost or the Docker Compose service name (e.g. postgres).Database server port. Default is the standard PostgreSQL port. Adjust if you run a non-standard port or use a different engine.
Name of the database to connect to. Create separate databases per environment (e.g.
lightpress_dev, lightpress_test, lightpress_prod) to prevent accidental data contamination.Database user that Lightpress services authenticate as. This user should have the minimum permissions required — typically
SELECT, INSERT, UPDATE, DELETE on application tables only.Password for
DB_USER. In production, retrieve this value from AWS Secrets Manager rather than storing it as a plaintext environment variable.Full connection string as an alternative to the individual
DB_* variables. Format: postgresql://user:password@host:port/dbname. When set, this takes precedence over the individual variables.AWS credentials and region
These variables are required when any Lightpress service interacts with AWS — for example, uploading files to S3, reading from SQS, or writing to DynamoDB.The AWS region where Lightpress resources are deployed (e.g.
us-east-1, eu-west-1). All AWS SDK calls default to this region.AWS access key ID for programmatic access. Required only for local development when you are not using an IAM role or AWS profile. On AWS infrastructure, leave this unset and rely on the instance/task role instead.
AWS secret access key paired with
AWS_ACCESS_KEY_ID. Same caveats apply — omit on AWS-hosted environments and use IAM roles.Name of the S3 bucket used for file storage (uploads, exports, static assets). The bucket must exist in the region specified by
AWS_REGION before services start.Full URL of the SQS queue used for async job processing between microservices. Format:
https://sqs.<region>.amazonaws.com/<account-id>/<queue-name>.Service URLs
Each microservice exposes an HTTP API. Other services and the client use these URLs to communicate internally.Base URL of the authentication service. Example:
http://localhost:3001 locally, or an internal load balancer DNS name in production.Base URL of the billing service. Required if billing features are enabled. Leave unset to disable billing-related functionality.
Base URL of the notifications service. Used by other services to trigger emails, push notifications, or webhooks.
Public-facing URL of the frontend client. Used by backend services to build redirect URLs and configure CORS allow-lists. Example:
http://localhost:5173 for local Vite dev server.Base URL of the API Gateway if traffic is routed through AWS API Gateway rather than directly to service load balancers. Leave unset to skip API Gateway routing.
Authentication
Secret used to sign and verify JSON Web Tokens. Must be a long, random string (minimum 32 characters). Generate with
openssl rand -hex 32. Rotate this value if it is ever exposed.Lifetime of access tokens issued by the auth service. Accepts any value parseable by the
ms package (e.g. 15m, 1h, 7d). Shorter values are more secure; pair with a refresh token strategy for long sessions.Separate secret for signing refresh tokens. Must differ from
JWT_SECRET.Lifetime of refresh tokens. Longer than
JWT_EXPIRY by design. Users are required to re-authenticate after this period.Feature flags
Feature flags let you enable or disable functionality at runtime without redeploying. All flags default tofalse (disabled) unless specified otherwise.
Enable the billing subsystem and expose billing-related API endpoints. Set to
true once you have configured Stripe keys and the billing service URL.Require new users to verify their email address before accessing the application. Disable only in development or test environments where you want to bypass the verification flow.
Enable per-IP and per-user rate limiting on public API endpoints. Disable only in local or test environments where automated tests would otherwise hit limits.
When
true, all API endpoints return a 503 Service Unavailable response with a maintenance message. Use during planned downtime or deployments that require data migrations.Quick reference
.env.example