// Write Radix platform notification messages for Slack. Use when: writing announcements, deprecation notices, action-needed alerts, maintenance windows, or breaking changes for Radix users.
Write and review Radix platform documentation. Use when: writing docs, editing docs, reviewing docs, creating guides, updating documentation pages, fixing doc style, proofreading, documentation review.
Update AGENTS.md when skills are added, removed, or modified. Use when: creating a new skill, deleting a skill, renaming a skill, updating a skill description, syncing AGENTS.md with current skills.
| name | radix-notification |
| description | Write Radix platform notification messages for Slack. Use when: writing announcements, deprecation notices, action-needed alerts, maintenance windows, or breaking changes for Radix users. |
| argument-hint | Describe the change, who is affected, and what action is needed |
Follow this structure. Not all sections are needed for every message — pick what applies.
Always start and end with :omniaradix:. Use a bold, descriptive title that tells users what the message is about at a glance.
:omniaradix: **Title describing the change** :omniaradix:
Immediately clarify who needs to act and who can ignore the message. If most users are unaffected, say so upfront to reduce noise.
**No action is needed if you do not use [feature X].**
Or use @channel if everyone is affected.
One or two sentences explaining the reason for the change. Focus on user benefits (security, performance, cost) rather than internal reasons.
Numbered steps, kept minimal. Link to migration guides or documentation rather than inlining instructions.
**What you need to do:**
1. Step one
2. Step two
See the migration guide: https://www.radix.equinor.com/...
Use :warning: for consequences. Be specific about dates if there is a deadline.
:warning: After [date], [consequence].
Or for soft pressure without a hard deadline:
:warning: [Resource/capacity] on the legacy option will be reduced. Please migrate at your earliest convenience.
If users can temporarily revert, tell them how — and ask them to contact the team so issues can be tracked.
:wrench: If you experience issues, contact the Radix team immediately. As a temporary fallback, you can [revert step] while we investigate.
Always end with an offer to help:
Don't hesitate to contact the Radix team if you have any questions.
:omniaradix: for header, :warning: for consequences, :wrench: for fallbacks, :muscle: or :hugging_face: only for light positive notesSee these past notifications for reference on tone and structure:
:omniaradix: **Action needed: Migrate to BuildKit for build secrets** :omniaradix:
Radix now defaults to using BuildKit (`useBuildKit: true`) for all builds. **No action is needed if you do not use build secrets.**
**If your application uses build secrets**, not setting `useBuildKit: true` is now **deprecated** and requires changes to your Dockerfile. The legacy build method passes secrets as `ARG`s, which is less secure. BuildKit mounts secrets as files, which is safer and allows us to implement new security features going forward. It is also faster in many cases.
**What you need to do:**
1. Set `useBuildKit: true` in the `spec.build` section of your `radixconfig.yaml`
2. Update your Dockerfile to mount build secrets as files instead of using `ARG`s
See the migration guide: https://www.radix.equinor.com/guides/build-secrets/#build-secrets-with-buildkit
:warning: Build capacity on the legacy option will be reduced for cost savings. Please migrate at your earliest convenience.
:wrench: If you experience any build issues with the new default, please contact the Radix team as soon as possible so we can investigate. As a temporary fallback, you can set `useBuildKit: false` in your `radixconfig.yaml` to revert to the legacy behavior while we resolve the issue.
Don't hesitate to contact the Radix team if you have any questions.
:omniaradix: Action needed: OAuth2 Header Migration :omniaradix:
@channel
As part of Radix platform upgrade, we are migrating away from ingress-nginx. This change impacts the OAuth2 feature.
If your application uses the OAuth2 feature, and have set the setXAuthRequestHeaders property to true in radixconfig.yaml, you need to update the application.
Update to rely on the X-Forwarded-* headers instead of X-Auth-Request-*.
Deadline: February 16, 2026
After which the X-Auth-Request-* headers will be removed.
Please refer to this migration guide for more details.
Don't hesitate to contact the Radix team if you have any questions.
:omniaradix: Radix Platform North Europe - Extend Egress IP ranges :omniaradix:
Important message to everyone who uses Radix Egress IP Firewall rules
Please update your incoming firewall rule to accept traffic from these networks:
[IP list]
(ref https://console.radix.equinor.com/about)
It is a good time to create Private Link to your resources instead
https://www.radix.equinor.com/guides/private-link/
If you use Private Links already...great :muscle:, you don't have to do anything :hugging_face:
:omniaradix: Networking Layer Reconfiguration :omniaradix:
We are reconfiguring the networking layer for Radix API and Radix Github Webhook service the next couple of hours.
This may cause a few minutes of downtime for webhook events and Radix API access in each of the clusters. This can cause dropped GitHub push events.
During this time, the Web Console and CLI might experience temporary issues.