You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a developer I would like to maintain environment-based configuration for Astro sessions after build time and have the ability to implement custom session drivers for specific use cases.
Background & Motivation
Currently, when building an Astro application with session support, environment variables used in the session configuration (such as process.env.REDIS_URL) are resolved at build time and hardcoded into the compiled output. This violates the third factor of the Twelve-Factor App methodology, which states that configuration should be stored in the environment (https://12factor.net/config).
For example, when configuring Redis sessions with url: process.env.REDIS_URL, the build output contains the hardcoded value "url":"redis://redis-service:6379" instead of maintaining the environment variable reference. This prevents the "build once, deploy multiple" approach that is essential for modern deployment practices.
Additionally, the current session implementation only supports a limited set of built-in drivers. Developers working with specialized storage solutions or unique requirements cannot implement their own custom session drivers, limiting the flexibility of the session system.
Goals
A concise, bulleted-list outlining the intended goals of this RFC:
Preserve environment variable references (process.env.*) in session configuration through the build process
Enable runtime resolution of session configuration values from environment variables
Support the "build once, deploy multiple" deployment pattern for Astro applications
Allow developers to register and use custom session drivers
Maintain backward compatibility with existing session configurations
Ensure that security-sensitive configuration (like database URLs) remains in environment variables
Example
The proposed changes would allow the following configurations to work properly:
1. Environment-based configuration (preserved at runtime):
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Body
Summary
As a developer I would like to maintain environment-based configuration for Astro sessions after build time and have the ability to implement custom session drivers for specific use cases.
Background & Motivation
Currently, when building an Astro application with session support, environment variables used in the session configuration (such as
process.env.REDIS_URL
) are resolved at build time and hardcoded into the compiled output. This violates the third factor of the Twelve-Factor App methodology, which states that configuration should be stored in the environment (https://12factor.net/config).For example, when configuring Redis sessions with
url: process.env.REDIS_URL
, the build output contains the hardcoded value"url":"redis://redis-service:6379"
instead of maintaining the environment variable reference. This prevents the "build once, deploy multiple" approach that is essential for modern deployment practices.Additionally, the current session implementation only supports a limited set of built-in drivers. Developers working with specialized storage solutions or unique requirements cannot implement their own custom session drivers, limiting the flexibility of the session system.
Goals
A concise, bulleted-list outlining the intended goals of this RFC:
process.env.*
) in session configuration through the build processExample
The proposed changes would allow the following configurations to work properly:
1. Environment-based configuration (preserved at runtime):
2. Custom driver implementation:
Beta Was this translation helpful? Give feedback.
All reactions