Add coder.httproute.httpsRedirect.statusCode to configure the HTTPRoute
redirect response code, defaulting to 308. Validate that the value is
one of 301, 302, 303, 307, or 308.
<!--
If you have used AI to produce some or all of this PR, please ensure you
have read our [AI Contribution
guidelines](https://coder.com/docs/about/contributing/AI_CONTRIBUTING)
before submitting.
-->
> Coder Agents generated this commit
Replace the with block around the Service nodePort field with an if
guard that references .Values.service.nodePort directly. The with form
rebinds the dot inside the block, so a later addition that needs .Values
or .Release there would break.
Extend the default_values fixture to enable ingress and httproute with
only the values each one requires, so the golden file covers every
template with the minimum viable configuration.
Add a mustNotContain list to the render test cases. Golden files are
rewritten wholesale by TestUpdateGoldenFiles, so these assertions pin
optional fields and resources that each fixture leaves unset, including
the Service nodePort.
Documents standalone AI Gateway deployment, Gateway key authentication,
monitoring, and the updated embedded vs standalone topology in the AI
Gateway docs.
---------
Co-authored-by: Cian Johnston <cian@coder.com>
Fixes an issue where the standalone AI Gateway waited for the initial
provider load before starting its HTTP server.
HTTP serving now starts independently of provider synchronization.
`/healthz` becomes available when the HTTP server starts, while
`/readyz` requires an active DRPC connection and completed initial
provider load.
Enables the Helm chart's startup and liveness probes by default because
liveness no longer depends on provider loading.
Adds the `coder-ai-gateway` Helm chart for deploying the Coder AI
Gateway as a standalone Kubernetes workload.
Adds the coder-ai-gateway Helm chart for deploying the Coder AI Gateway as a standalone Kubernetes workload.
The chart supports AI Gateway keys from an existing Secret or environment configuration, Coder connectivity through CODER_URL, listener and Coder-facing TLS, and optional Service, Ingress, and Gateway API HTTPRoute resources.
Integrates the chart with existing Helm build, lint, golden generation, release artifact, Helm repository, and OCI publishing workflows.
The golden files from #24993 were generated against a stale fork that
predated the `CODER_CLUSTER_HOST` env var addition. This regenerates
them against current main.
All 4 files just need the missing env var block:
```yaml
- name: CODER_CLUSTER_HOST
valueFrom:
fieldRef:
fieldPath: status.podIP
```
Fixes the `gen` / `TestRenderChart` failures tracked in
https://github.com/coder/internal/issues/1611#issuecomment-4835998513.
---
*PR created by [Coder Agents](https://coder.com/docs/ai-coder) on behalf
of @bpmct*
Closes GRU-69
Adds CODER_CLUSTER_HOST enviroment variable and CLI arg.
I ended up not making it hidden since we'll just have to unhide it later and even when hidden it still shows up in some autogenerated stuff. Might as well just go for it.
I also added it to the helm chart.
Closes [DOCS-256](https://linear.app/coder/issue/DOCS-256). Sibling to
[DOCS-253](https://linear.app/coder/issue/DOCS-253) (#25740).
Updates docs URL references across the non-TypeScript surface of
`coder/coder` to match the current docs site structure. Source-of-truth
for redirects is `coder/coder.com/redirects.json` (parent ticket
[DOCS-209](https://linear.app/coder/issue/DOCS-209)).
## What changed
| Area | Files | URL mapping |
|---|---|---|
| Top-level README | `README.md` | `/docs/workspaces` ->
`/docs/user-guides/workspace-management`, `/docs/templates` ->
`/docs/admin/templates`, `/docs/ides` ->
`/docs/user-guides/workspace-access` |
| Docs source | `docs/admin/security/0001_user_apikeys_invalidation.md`
| `/docs/admin/audit-logs` -> `/docs/admin/security/audit-logs` |
| Docs source | `docs/install/cloud/azure-vm.md` |
`/docs/coder-oss/latest/install` -> `/docs/install` |
| Dogfood | `dogfood/coder/guide.md` | `/docs/ides` ->
`/docs/user-guides/workspace-access` |
| Helm | `helm/coder/values.yaml` | `/docs/admin/workspace-proxies` ->
`/docs/admin/networking/workspace-proxies` |
| Enterprise coderd | `enterprise/coderd/coderd.go` |
`/docs/admin/encryption` -> `/docs/admin/security/database-encryption`
(error message) |
| Release tooling | `scripts/release/main_internal_test.go` |
`/docs/admin/upgrade` -> `/docs/install/upgrade` (test fixture, matches
`generate_release_notes.sh`) |
| AI bridge | `aibridge/client.go` | repinned to current `main` SHA on
renamed `docs/ai-coder/ai-gateway/monitoring.md`, line range `#L47-L57`
|
| Example templates | 12 `examples/templates/*/README.md`,
`examples/parameters/*`,
`examples/parameters-dynamic-options/README.md`,
`examples/workspace-tags/README.md`, `examples/parameters/main.tf`,
`examples/examples.gen.json` (regenerated) | `/docs/workspaces` ->
`/docs/user-guides/workspace-management`, `/docs/templates/parameters`
-> `/docs/admin/templates/extending-templates/parameters`,
`/docs/templates/dev-containers` ->
`/docs/admin/integrations/devcontainers`, `/docs/dotfiles` ->
`/docs/user-guides/workspace-dotfiles`,
`/docs/about/architecture#agents` ->
`/docs/admin/infrastructure/architecture#agents` |
| Live notification templates (DB) | New migration
`000510_fix_dormancy_notification_docs_urls.up.sql` and `.down.sql` plus
the four regenerated SMTP/webhook goldens under
`coderd/notifications/testdata/rendered-templates/` |
`/docs/templates/schedule#dormancy-threshold-enterprise` ->
`/docs/admin/templates/managing-templates/schedule#dormancy-threshold`,
`/docs/templates/schedule#dormancy-auto-deletion-enterprise` ->
`/docs/admin/templates/managing-templates/schedule#dormancy-auto-deletion`
|
The migration uses `REPLACE(body_template, ...)` scoped by template id
and `LIKE '%/docs/templates/schedule%'`, so it works regardless of which
intermediate state (`000232`, `000262`, `000305`, or `000311`) is
currently in the row.
## What did not change
Historical SQL migrations `000232`, `000262`, `000305`, and `000311` are
not modified because migrations are immutable history. The 18 remaining
stale URL references in those files are superseded at runtime by
migration `000510`. This decision matches the pattern used in the A1
sister PR (#25740).
## Verification
- `go test ./coderd/database/migrations/... -count=1` (UP+DOWN)
- `go test ./coderd/notifications/ -run TestNotificationTemplates_Golden
-update -count=1` to regenerate the four `.golden` files
- `go test ./scripts/release/ -run Test_removeMainlineBlurb -count=1`
- `make pre-commit` (gen + fmt + lint + slim build) ran clean as part of
the commit hook
I also fixed a pre-existing emdash on line 35 of
`examples/templates/azure-linux/README.md` that the lint flagged once
the file entered my diff. The line was already in `main`, but `make gen`
rewrites `examples/examples.gen.json` whenever a `README.md` changes, so
the line came back as a `+` in the diff against `origin/main` and the
`lint/emdash` step refused it.
<details>
<summary>Pre-mortem</summary>
| Risk | Mitigation |
|---|---|
| Migration overwrites future template edits | Used `REPLACE` instead of
full body overwrite. `WHERE id IN (...) AND body_template LIKE
'%/docs/templates/schedule%'` further scopes the write |
| Goldens drift from migrated body | Regenerated goldens via `-update`
after the migration was in place, so the goldens reflect the
post-migration state |
| Down migration leaves stale URLs | Down migration reverses the REPLACE
so a rollback restores the prior URLs |
| Fragment loss when redirect strips fragment | Verified the destination
`schedule.md` contains `## Dormancy threshold` and `## Dormancy
auto-deletion` anchors |
| Terraform parse breakage in `examples/parameters/main.tf` | Only
comments changed; Terraform parser is unaffected |
| Test fixtures in `scripts/release` diverging from
`generate_release_notes.sh` | Updated to match the script, which already
emits `/docs/install/upgrade` |
</details>
---
Generated by Coder Agent on behalf of @nickvigilante.
## Summary
Previously, `CODER_PPROF_ADDRESS` and `CODER_PROMETHEUS_ADDRESS` were
hardcoded in the Helm chart template to `0.0.0.0:6060` and
`0.0.0.0:2112` respectively. These values could not be overridden via
`coder.env` values because the hardcoded values were set first in the
template, and Kubernetes uses the first occurrence of duplicate env
vars.
This was a security concern because binding to `0.0.0.0` exposes these
endpoints to any pod in the cluster:
- **pprof** can expose sensitive runtime information (goroutine stacks,
heap profiles, CPU profiles that may contain memory contents)
- **Prometheus metrics** may contain sensitive operational data
## Changes
1. **`helm/coder/templates/_coder.tpl`**: Added logic to check if the
user has set `CODER_PPROF_ADDRESS` or `CODER_PROMETHEUS_ADDRESS` in
`coder.env` before applying the default values. If the user provides a
value, the hardcoded default is skipped.
2. **`helm/coder/values.yaml`**: Updated documentation to:
- Remove these vars from the "cannot be overridden" list
- Add them to a new "can be overridden" section with security
recommendations
3. **Tests**: Added test cases for both override scenarios with
corresponding golden files.
## Usage
Users can now restrict pprof and prometheus to localhost only:
```yaml
coder:
env:
- name: CODER_PPROF_ADDRESS
value: "127.0.0.1:6060"
- name: CODER_PROMETHEUS_ADDRESS
value: "127.0.0.1:2112"
```
## Local Testing
To verify the fix locally:
```bash
# Update helm dependencies
cd helm/coder && helm dependency update
# Test default behavior (should show 0.0.0.0)
helm template coder . -f tests/testdata/default_values.yaml --namespace default | grep -A1 'CODER_PPROF_ADDRESS\|CODER_PROMETHEUS_ADDRESS'
# Test pprof override (should show 127.0.0.1:6060)
helm template coder . -f tests/testdata/pprof_address_override.yaml --namespace default | grep -A1 'CODER_PPROF_ADDRESS'
# Test prometheus override (should show 127.0.0.1:2112)
helm template coder . -f tests/testdata/prometheus_address_override.yaml --namespace default | grep -A1 'CODER_PROMETHEUS_ADDRESS'
# Run Go tests
cd tests && go test . -v
```
Fixes#21713
---------
Co-authored-by: blink-so[bot] <211532188+blink-so[bot]@users.noreply.github.com>
Co-authored-by: uzair-coder07 <uzair@coder.com>
Liveness checks are currently causing pods to be killed during
long-running migrations.
They are generally not advisable for our workloads; if a pod becomes
unresponsive we _need_ to know about it (due to a deadlock, etc) and not
paper over the issue by killing the pod.
I've also made all probe settings configurable.
---------
Signed-off-by: Danny Kopping <danny@coder.com>
**Add priorityClassName support to Coder Helm chart**
Add coder.priorityClassName configuration to the Helm chart that allows
setting the pod's priorityClassName in the deployment
**Usage:**
```
coder:
priorityClassName: high-priority
```
See: https://github.com/coder/coder/discussions/20676
---------
Co-authored-by: Rowan Smith <rowan@coder.com>
This is a feature to create Role & RoleBinding entries on a per
namespace basis to support deploying workspaces in separate namespace to
where Coder is deployed. The idea behind this is to avoid the creation
of custom RBAC entries or the use of ClusterRoles (in order to maintain
priciple of least privilege).
> If you have used AI to produce some or all of this PR, please ensure
you have read our [AI Contribution
guidelines](https://coder.com/docs/about/contributing/AI_CONTRIBUTING)
before submitting.
This is a blink assisted PR.
Example `helm template` without
`coder.serviceAccount.workspaceNamespaces` enabled (existing behaviour
as of current release) is below. Outcome = 1 x SA, 1 x Role, 1 x
RoleBinding, all in the coder (`.Release.Namespace`) namespace.
```
➜ coder git:(feat/helm_namespace_rbac_improvements) ✗ helm template -n coder coder . --set coder.image.tag=v2.25.1
---
...
---
# Source: coder/templates/rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: coder-workspace-perms
namespace: coder
rules:
- apiGroups: [""]
resources: ["pods"]
verbs:
- create
- delete
- deletecollection
- get
- list
- patch
- update
- watch
- apiGroups: [""]
resources: ["persistentvolumeclaims"]
verbs:
- create
- delete
- deletecollection
- get
- list
- patch
- update
- watch
- apiGroups:
- apps
resources:
- deployments
verbs:
- create
- delete
- deletecollection
- get
- list
- patch
- update
- watch
---
# Source: coder/templates/rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: "coder"
namespace: coder
subjects:
- kind: ServiceAccount
name: "coder"
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: coder-workspace-perms
---
```
Example `helm template` *with*
`coder.serviceAccount.workspaceNamespaces` enabled is below. Outcome = 1
x SA, 1 x Role, 1 x RoleBinding, all in the coder (`.Release.Namespace`)
namespace PLUS a Role and RoleBinding in the `dev-ws` namespace with
each of the RoleBindings referencing the coder SA in the coder
(`.Release.Namespace`) namespace:
```
➜ coder git:(feat/helm_namespace_rbac_improvements) ✗ helm template -n coder coder . --set coder.image.tag=v2.25.1 --set-json 'coder.serviceAccount.workspaceNamespaces=[{"name":"dev-ws","workspacePerms":true,"enableDeployments":true,"extraRules":[]}]'
---
...
---
# Source: coder/templates/rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: coder-workspace-perms
namespace: coder
rules:
- apiGroups: [""]
resources: ["pods"]
verbs:
- create
- delete
- deletecollection
- get
- list
- patch
- update
- watch
- apiGroups: [""]
resources: ["persistentvolumeclaims"]
verbs:
- create
- delete
- deletecollection
- get
- list
- patch
- update
- watch
- apiGroups:
- apps
resources:
- deployments
verbs:
- create
- delete
- deletecollection
- get
- list
- patch
- update
- watch
---
# Source: coder/templates/rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: coder-workspace-perms
namespace: dev-ws
rules:
- apiGroups: [""]
resources: ["pods"]
verbs:
- create
- delete
- deletecollection
- get
- list
- patch
- update
- watch
- apiGroups: [""]
resources: ["persistentvolumeclaims"]
verbs:
- create
- delete
- deletecollection
- get
- list
- patch
- update
- watch
- apiGroups:
- apps
resources:
- deployments
verbs:
- create
- delete
- deletecollection
- get
- list
- patch
- update
- watch
---
# Source: coder/templates/rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: "coder"
namespace: coder
subjects:
- kind: ServiceAccount
name: "coder"
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: coder-workspace-perms
---
# Source: coder/templates/rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: "coder"
namespace: dev-ws
subjects:
- kind: ServiceAccount
name: "coder"
namespace: coder
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: coder-workspace-perms
---
```
**Add pod-level securityContext support to Coder Helm chart**
Adds `coder.podSecurityContext` field to enable pod-level security
settings, primarily to solve TLS certificate mounting permission issues.
**Problem**: When mounting TLS certificates from Kubernetes secrets, the
Coder process (UID 1000) cannot read the files due to restrictive
permissions.
**Solution**: Setting `podSecurityContext.fsGroup: 1000` ensures
Kubernetes sets group ownership of mounted volumes to GID 1000, allowing
the Coder process to read certificate files.
**Changes**:
- Added `podSecurityContext` field to values.yaml with documentation
- Updated `_coder.yaml` template to include pod-level security context
- Added test case and golden files
- Maintains backward compatibility (opt-in feature)
**Usage**:
```yaml
coder:
podSecurityContext:
fsGroup: 1000 # Enables TLS cert access
```
Fixes#19038
Makes `initialDelaySeconds` configurable for both `readinessProbe` and
`livenessProbe` in the Helm chart.
**Changes:**
- Added `coder.readinessProbe.initialDelaySeconds` and
`coder.livenessProbe.initialDelaySeconds` to `values.yaml`
- Updated `_coder.tpl` template to use these configurable values
- Defaults to 0 seconds to maintain existing behavior
**Testing:**
- Verified template rendering with default values (0)
- Verified template rendering with custom values (30, 60)
- Both probes correctly use the configured `initialDelaySeconds`
---------
Co-authored-by: blink-so[bot] <211532188+blink-so[bot]@users.noreply.github.com>
Co-authored-by: kylecarbs <7122116+kylecarbs@users.noreply.github.com>
- Update go.mod to use Go 1.24.1
- Update GitHub Actions setup-go action to use Go 1.24.1
- Fix linting issues with golangci-lint by:
- Updating to golangci-lint v1.57.1 (more compatible with Go 1.24.1)
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
---------
Co-authored-by: Claude <claude@anthropic.com>
For production deployments we recommend disabling the default GitHub
OAuth2 app managed by Coder. This PR mentions it in k8s installation
docs and the helm README so users can stumble upon it more easily.
Added namespace to all resources in the helm chart and added tests to ensure that coder can be deployed in non-default namespaces, as specified via the namespace flag in the helm command.
Ways to verify this:
- current state:
```bash
$ helm template my-coder coder -n coder --version 2.19.0 --repo https://helm.coder.com/v2 | yq '.metadata.namespace'
null
---
null
---
null
---
null
---
null
```
- fixed state when checking out this PR:
```bash
$ helm template my-coder ./helm/coder -n coder --set coder.image.tag=latest | yq '.metadata.namespace'
coder
---
coder
---
coder
---
coder
---
coder
```
Change-Id: Ib66d4be9bcc4984dfe15709362e1fe0dcd3e847f
Signed-off-by: Thomas Kosiewski <tk@coder.com>
## Short description:
This pull request introduces support for optionally specify `nodePort`
values when using `LoadBalancer` service type in the Coder Helm chart.
This enhancement addresses a limitation where `httpNodePort` and
`httpsNodePort` values were previously ignored for `LoadBalancer`
services. This PR should expand the service customization options
without disrupting existing configurations.
## Why this is Useful
In some enterprise environments, applications may be required to use
specific ports for compliance with organizational policies or cloud
infrastructure requirements. For instance:
- Reserved port blocks are allocated for specific applications for
security and clarity.
- Ensuring predictable port assignments helps in debugging and
management scenarios.
Since LoadBalancer in Kubernetes operates on top of nodePort, this
feature is useful for enabling enterprises to adhere to such policies if
they whish.
## What Was Changed
- Updated helm/coder/templates/service.yaml:
- Allowed nodePort specification for both NodePort and LoadBalancer
service types.
- Updated helm/coder/templates/values.yaml:
- Updated inline comments to reflect the changes for nodeport values use
cases.
### Regarding backward compatibility:
If nodePort is not specified, Kubernetes dynamically assigns a port,
maintaining the current behavior.
### Testing Performed
- Validated through Helm dry-run: nodePort values are rendered correctly
in the resulting Kubernetes YAML.
- Deployed the updated chart in an enterprise Kubernetes cluster.
- Tested coder environment with LoadBalancer service and specified
nodePort values for both HTTP and HTTPS.
## Additional Notes
- This PR expands the nodeport functionality introduced in PR #8993 to
the Loadbalancer service.
- If merged, an update to the documentation to include examples of
LoadBalancer with nodePort values may be useful.
- I've read the contributing guidelines and code of conduct. This is my
first PR for the Coder project, and I hope it meets the community
standards. Any advice, feedback, or help is greatly appreciated!
Fixes https://github.com/coder/coder/issues/15437
- Adds support for `coder.serviceAccount.disableCreate` (originally
added to `helm/coder` in https://github.com/coder/coder/pull/14817).
- Adds documentation and examples in `helm/provisioner/README.md` on
deploying multiple provisioners in the same namespace leveraging
`nameOverride`.
Relates to https://github.com/coder/coder/pull/15416
This PR modifies the provisioner helm chart logic:
- Previously, when both provisionerDaemon.keySecretName and provisionerDaemon.pskSecretName
were both set, we would fail to install the chart. This required users to have an obnoxious workaround
in place where setting provisionerDaemon.pskSecretName="" was required in order to use provisioner
keys. We now check for pskSecretName being set to the default value when keySecretName is also specified,
and switch to provisioner key authentication instead of PSK. The previous workaround is still supported.
- We also had omitted to check for provisionerd.Tags being set along with provisionerDaemon.keySecretName.
This would result in a crashlooping provisioner deployment, as setting both of these configuration options is
not allowed. We now fast-fail the Helm deployment if we detect this scenario.
The go tests that would have checked for the outdated golden files
didn't get run as part of https://github.com/coder/coder/pull/14817
because only `helm/**` files were modified.
- Adds `provisionerDaemon.keySecretName` and
`provisionerDaemon.keySecretKey`
- Omitting `provisionerDaemon.pskSecretName` will now cause the PSK
secret to no longer be created.
- Adds a note in `NOTES.txt` regarding provisioner PSKs.
- Adds validation that either `provisionerDaemon.keySecretName` or
`provisionerDaemon.pskSecretName` is specified, and will fail the
install in this case.
This PR removes the prometheus-http port entirely from the coder service specification (originally added in #10448). It also removes the Helm value coder.service.prometheusNodePort.
Rationale: some cloud providers will helpfully expose all ports on a LoadBalancer service for you. The net effect of this is that setting CODER_PROMETHEUS_ENABLE will end up exposing port 2112 on your coderd service to the internet, which is likely undesired behaviour.
Stefan Richter