Namespaces
Namespaces partition resources logically — services, secrets, and configmaps live inside one.
A namespace is a logical scope for resources. Two services can share a name as long as they're in different namespaces. Tokens, policies, and namespaces themselves live in the special system namespace.
Built-in namespaces
| Namespace | Purpose |
|---|---|
default | Where workloads land if you don't specify one. |
system | Internal — tokens, users, policies, namespaces. You rarely touch it. |
Both are seeded automatically on first server start.
Creating a namespace
rune create namespace prod
rune create namespace staging
Or declaratively:
namespace:
name: prod
description: Production workloads
rune cast prod-ns.yaml
Using a namespace
Most commands take -n / --namespace:
rune get services -n prod
rune cast api.yaml -n prod
rune scale api 5 -n prod
Or set a default per context:
rune login prod \
--server runed.example.com:7863 \
--token-file ./prod.token \
--namespace prod
Now rune defaults to prod for that context.
The service.namespace: field in your YAML wins over -n if both are set, so prefer one approach per environment.
Cross-namespace references
Most things are scoped to a single namespace. The exceptions:
- Tokens, users, policies live in
systemand are global. - Service dependencies can target other namespaces explicitly:
dependencies: - service: postgres namespace: data
Secrets and configmaps cannot be referenced across namespaces. Copy them or use a runeset.
Listing across namespaces
rune get services --all-namespaces
This requires a policy that allows the verb in * namespace.
Listing namespaces
rune get namespaces
Deleting a namespace
rune delete namespace staging
Refuses if the namespace contains resources unless you pass --force (cascade delete).