Improve documentation about ASTRO_KEY#11751
Conversation
✅ Deploy Preview for astro-docs-2 ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
Lunaria Status Overview🌕 This pull request will trigger status changes. Learn moreBy default, every PR changing files present in the Lunaria configuration's You can change this by adding one of the keywords present in the Tracked Files
Warnings reference
|
|
Hello! Thank you for opening your first PR to Astro’s Docs! 🎉 Here’s what will happen next:
|
f9fe6c7 to
6763471
Compare
| In environments with rolling deployments (e.g., Kubernetes), your frontend assets (which encrypt props) and your backend functions (which decrypt props) may be temporarily out of sync. By default, Astro generates a new random key on each build. If the frontend and backend use different keys - or if a CDN is still serving pages built with an old key - encrypted props cannot be decrypted, causing server islands to fail. | ||
|
|
||
| To solve this, you can create a key with the Astro CLI and then reuse it for all of your deployments. This ensures that each user's frontend is talking to a backend that has the right key. | ||
| To ensure both sides use the same key, you must supply the `ASTRO_KEY` environment variable **during the build**. This embeds always the same key into the generated bundle so that encryption and decryption remain in sync. |
There was a problem hiding this comment.
As this is a new paragraph it might be unclear that this only applies if you are doing rolling deployments, and that most users don't need to worry about it.
There was a problem hiding this comment.
Agree, I added an additional note that setting an ASTRO_KEY is probably not needed for most users.
|
|
||
| ### Generating and configuring a reusable key | ||
|
|
||
| Use the Astro CLI to generate a reusable key: |
There was a problem hiding this comment.
I have seen people getting confused, thinking that the required value is just a random string rather than an actual encoded key in a specific format.
There was a problem hiding this comment.
True, I adjusted the last section to make clear that the output ASTRO_KEY is not just a random string but an encoded encryption key
cd42c83 to
95f6d8a
Compare
sarah11918
left a comment
There was a problem hiding this comment.
Thanks, both, for contributing to this docs improvement! 🙌
Annoyingly, GitHub won't allow me to make the suggestions I'd like so I can Astro-Docs-Style this thing up, so you're gonna get one big block for the whole thing for your consideration. 😅
| @@ -97,20 +97,26 @@ const productId = url.searchParams.get('product'); | |||
|
|
|||
| ## Reusing the encryption key | |||
There was a problem hiding this comment.
| ## Reusing the encryption key | |
| ## Reusing the encryption key | |
| Astro uses [cryptography](https://developer.mozilla.org/en-US/docs/Glossary/Cryptography) to encrypt props passed to server islands, protecting sensitive data from accidental exposure. This encryption relies on a new, random key that is generated on each build and embedded in the server bundle. | |
| Most deploy hosts will handle keeping your front end and back end in sync automatically. However, you may need a constant encryption key if you are using rolling deployments, multi-region hosting or a CDN that caches pages containing server islands. | |
| In environments with rolling deployments (e.g., Kubernetes) where your frontend assets (which encrypt props) and your backend functions (which decrypt props) may be temporarily using different keys, or when a CDN is still serving pages built with an old key, then encrypted props passed to your server island cannot be decrypted. | |
| In these situations, use the Astro CLI to generate a reusable, encoded encryption key to set as an environment variable in your build environment: | |
| ```shell | |
| astro create-key | |
| ``` | |
| Use this value to configure the `ASTRO_KEY` environment variable (e.g. in a `.env` file) and include it in your CI/CD or host's build settings. This ensures the same key is always reused in the generated bundle so that encryption and decryption remain in sync. |
OK, it's a nightmare to try to make suggestions in the GitHub UI with all the line deletions etc., but here is my suggestion for presenting all this information in a way that conforms to Astro Docs style. (No overuse of notes/asides; combining info to avoid repetition; etc.)
See what you think, and of course, I'll rely on you both for correcting any nuance or facts that might have shifted during the flight. 😄
There was a problem hiding this comment.
Awesome, thanks for looking into this. Your version sounds great, will implement the changes into my branch. 👍
95f6d8a to
2c22991
Compare
sarah11918
left a comment
There was a problem hiding this comment.
Thank you for taking the time to improve this section, @dpuscher ! We appreciate the effort, and are happy to welcome you to Team Docs! 🥳
Description (required)
This PR refines the "Reusing the encryption key" section in the Server Islands guide to enhance clarity and conciseness. The updated content emphasizes the necessity of setting
ASTRO_KEYduring the build phase.Related issues & labels (optional)
docs