Networking
The Networking section of the Cockpit lets you create and manage ingresses and certificates, handle redirects and configure your desired redirect settings, and manage secrets.
Select desired cluster
Select your desired cluster from the dropdown menu at the top of the Cockpit.

Ingresses
Kubernetes Ingresses manage external access to services within a cluster, enabling HTTP and HTTPS traffic routing based on hostnames and paths. They provide a flexible, scalable way to expose Magnolia applications, supporting features like SSL termination, load balancing, and custom Nginx configurations. Ingresses are essential for delivering secure, performant web experiences in the DX Cloud Cockpit.
In this section, you can find:
-
Instructions to add an Ingress in the Cockpit
You can also find embedded help directly in the Cockpit.
Add a Federation
-
In the Cockpit, go to Admin > Federations.
-
Enter a Display name for your Federation. This autofills the Alias field.
-
Check the box for Enabled if you want to enable the Federation.
-
Select the type of the Federation. This is either OIDC or SAML.
The following are required:
-
Enter the Authorization URL.
-
Enter the Token URL.
-
Enter the Client ID.
-
Enter the Client secret.
The remainig are optional but recommended:
-
Enter the Logout URL.
-
Enter the User info URL.
-
Enter the Issuer.
-
Check the box for Validate signature if you want to validate the signature of the IDP token.
-
Check the box for Use JWKs URL if you want to use the JWKs URL to validate the signature of the IDP token.
-
Enter the JWKs URL.
The following are required:
-
Enter the SAML Metadata.
The remaining are optional but recommended:
-
Enter the Name ID Policy Format.
-
Enter the Principal Type. Use
NameID
.
-
-
Under Advanced settings, choose the Sync Mode. This is either Force on every login or Import only on first login.
-
Check the box for Trust Email if you want to trust the email of the user.
General settings
Alias
🏷️ Alias
The alias is used to identify the Federation in the system. This is the same as the Display name you enter when adding a Federation.
OpenID Connect settings
Authorization URL
🏷️ Authorization URL
The Authorization URL is the endpoint where the identity provider redirects the user after a successful authentication.
https://let.me.in.com
Token URL
🏷️ Token URL
The Token URL is the endpoint where the identity provider returns the access token.
https://get.my.token.com
Client ID
🏷️ Client ID
The Client ID is the unique identifier of the application in the identity provider.
You should get this from your Identity Provider.
jamesbond
Client secret
🏷️ Client secret
The Client secret is the secret key used to authenticate the application in the identity provider.
You should get this from your Identity Provider.
superFlyTopSecret5000
Logout URL
🏷️ Logout URL
The Logout URL is the endpoint where the identity provider redirects the user after a successful logout.
User info URL
🏷️ User info URL
The User info URL is the endpoint where the identity provider returns the user information.
Validate signature
🏷️ Validate signature
Click the checkbox to validate the signature of the IDP token.
Claim an Ingress
Claiming an Ingress designates the Cockpit as the primary tool for managing its configuration, ensuring that subsequent changes are made through the Cockpit and external updates (e.g., via Rancher or CI/CD pipelines) are ignored when publishing. Once claimed, the Cockpit’s, external changes are overwritten when publishing from the Cockpit. Only healthy ingresses, those without synchronization warnings, can be claimed and managed via the Cockpit.
After claiming an Ingress, ensure it is managed exclusively through the Cockpit to avoid conflicts. Changes made externally (e.g., in Rancher or via Establish clear ownership for each Ingress, choosing one management approach:
|
To claim an Ingress:
-
Go to Networking > Ingresses.
-
Choose the desired Ingress.
-
Under the details section click Claim.
Validation Severity Levels
Ingress validation issues are categorized into two severity levels:
-
Warnings : These ingresses are functional but fail validation checks, preventing them from being claimed. Warnings indicate issues that must be resolved at the infrastructure level (e.g., via Rancher). After fixing the issues, trigger a Synchronization in the Cockpit to revalidate the Ingress. If no synchornization warnings remain, the Ingress can be claimed. Attempting to claim an Ingress with synchronization warnings will result in an
HTTP 422
status code from the backend. -
Errors : Ingresses with errors are non-functional and can be claimed to allow fixes directly in the Cockpit. Use the Cockpit interface to edit and resolve these errors, restoring the Ingress to a healthy state.
To troubleshoot validation issues, check the Ingress details in the Cockpit or consult your Kubernetes management tool (e.g., Rancher) for specific error messages. |
Synchronize an Ingress
Synchronization updates the Cockpit’s view of an unclaimed Ingress to reflect its current configuration in the Kubernetes cluster (e.g., managed via Rancher). Synchronization allows users to review the Ingress’s state in the Cockpit before deciding to claim it for Cockpit management. Synchronization is not available for claimed Ingresses, as claiming stops this process to ensure the Cockpit controls the Ingress’s configuration.
Ingresses created in the Cockpit are typically claimed and aligned with Kubernetes upon publishing, so synchronization is only needed if external changes or validation issues arise.
Synchronization is only for unclaimed ingresses. After claiming an Ingress, the Cockpit manages the Ingress exclusively, and synchronization is disabled. External changes to a claimed Ingress (e.g., via Rancher) are not reflected in the Cockpit and are overwritten by a Cockpit publish. Manage claimed ingresses exclusively through the Cockpit to avoid issues. |
Why Synchronize?
Synchronization is used when:
-
You need to view the latest Kubernetes configuration of an unclaimed Ingress (e.g., created in Rancher or modified externally) in the Cockpit before claiming it.
-
Validation warnings have been fixed at the infrastructure level (e.g., in Rancher), and you need to revalidate an unclaimed Ingress to confirm it’s claimable.
Ingresses created in the Cockpit are typically claimed and synced with Kubernetes upon publishing, so synchronization is rarely needed unless external changes occur before claiming. Ingresses created in Rancher or other Kubernetes tools require synchronization to appear accurately in the Cockpit before claiming. |
How to synchronize an Ingress
To synchronize an Ingress:
-
In the Cockpit, go to Networking > Ingresses.
-
Select an unclaimed Ingress from the list.
-
Verify that no unpublished changes exist in the Cockpit (e.g., check for pending edits in the Ingress details).
-
Click the Synchronize button.
The Cockpit then pulls the Ingress’s current configuration from the Kubernetes cluster, updates its database, and revalidates the Ingress.
If validation errors persist (e.g., resulting in an HTTP 422
status code), resolve them at the infrastructure level and synchronize again.
Best Practices
-
Choose a management tool: Decide whether an Ingress is managed via the Cockpit, a CI/CD pipeline, or manually (e.g., Rancher). Synchronize unclaimed ingresses to review their state, then claim them for Cockpit management if desired.
-
Check before synchronizing: Ensure no temporary Cockpit edits are critical, as they will be lost during synchronization.
-
Synchronize selectively: Use synchronization only when needed (e.g., to review external changes or revalidate warnings). After claiming, manage the Ingress exclusively via the Cockpit.
-
Monitor Ingress health: After synchronizing, check for validation warnings () or errors () in the Cockpit.
-
Troubleshoot issues: If synchronization fails, verify the Ingress configuration in Rancher or with
kubectl get Ingress
to identify discrepancies.
Manage certificates
You can manage your own certificates directly in the Cockpit under the Networking section. You can either choose to add a managed certificate or add a custom certificate.
The Networking > Certificates section displays useful information in a table format including the certificate status, validity period, and whether or not the certificate is custom. You can also filter by Type, Method, and Status.
Managed
Managed certificates involve fewer manual steps on your side. Once set up, we take care of everything, ensuring your certificate stays valid and up to date.
You have two options, including HTTP-01 which is the most straight forward option and DNS-01 which involves just a few minor steps. See the tabs below to decide which option is best for your DX Cloud project.
Triggers automatically if your ingress includes the cert-manager.io/cluster-issuer
annotation (e.g., for LetsEncrypt).
ingress:
enabled: true
annotations:
cert-manager.io/cluster-issuer: "letsencrypt-prod" (1)
1 | Specifies the issuer. Also, automatically triggers a managed certificate when applied. |
In this case, no DNS changes are required as it verifies via a temporary HTTP endpoint.
Best for: Simple setups where the domain is publicly accessible from port 80
.
You need to add the provided CNAME
record to your domain’s DNS settings to prove ownership.
Best for: Wildcard certificates
Custom
You have more control with custom certificates. However, with more control comes more steps for you. You manage your certificate through a Certificate Signing Request (CSR).
You’ll generate a CSR through the Cockpit, then use it to request a signed certificate from your Certificate Authority (CA).
Once you receive the signed certificate, upload it back into our Cockpit. From there, you retain full control over the certificate’s lifecycle, including renewals and updates.
See Add certificate for Cockpit instructions.
- Actions
Add certificate
This section provides guidance on adding both managed and custom certificates.
There are some limitations for certificates:
-
The maximum number of subdomains per domain is 100.
-
The maximum subdomain and domain length combined is 250 characters.
-
You should add a certificate with either a RSA 2048, RSA 4096, EC P-256, or EC P-384 key.
-
You can use wildcards for custom certificates, which are handled as part of these instructions. However, if using LetsEncrypt, you must file a Support request for wildcard certificates.
Managed certificates
View from the Cockpit
-
Go to your Cockpit and navigate to Networking > Certificates.
-
Click Add certificate.
-
Click Add managed certificate.
-
Give the certificate a Name. The name must match the Kubernetes resource naming scheme (e.g.,
example-certificate
).Names must start with a letter and can contain letters, numbers, hyphens (
-
), and underscores (_
) only. -
Select the Key size for your certificate.
Key sizes explained
-
Enter your Domain (e.g.,
example.com
). -
Choose the Issuer from the dropdown menu.
Currently, this is limited to LetsEncrypt.
-
Click Add managed certificate.
-
If using HTTP-01 (via Ingress annotation), no further steps are needed.
-
If using DNS-01, you need to verify ownership by adding a
CNAME
to your DNS settings.
-
Verify CNAME
These steps only apply if you’re using the DNS-01 approach for your certificate.
-
Go to your Cockpit and navigate to Networking > Certificates.
-
From the table, select your managed certificate.
-
On the right, click the green circle with lines.
-
Click Verify CNAME.
-
In the dialog, copy the
CNAME
.Example_acme-challenge.example.com. IN CNAME 1234beq2-1234-112A-3w21-12380ab31t2t.auth.host.com.
-
Paste the
CNAME
into your DNS settings.
This allows Magnolia to verify you have control over the domain and delegate the resolution of ACME challenges, to our infrastructure.
The system constantly checks the presence of this record in the background. Keep the entry in your DNS as long as the domain should be managed by Magnolia. Automatic certificate issuance and renewal starts as soon as the record has been created.
Change algorithm
You can change the algorithm (RSA, ECDSA) and key size of a Let’s Encrypt managed certificate through the Cockpit. This is useful if your organization requires stronger encryption or if you want to optimize performance with a more efficient algorithm.
Changing the algorithm or key size always creates a new certificate and private key. |
Custom certificates
View from the Cockpit
-
Go to your Cockpit and navigate to Networking > Certificates.
-
Click Add certificate.
-
Click Add custom certificate.
-
Give the certificate a Name.
Names must start with a letter and can contain letters, numbers, hyphens (
-
), and underscores (_
) only. -
Select the Key size for your certificate.
Key sizes explained
-
Enter an Alternative name for your certificate. This will autofill the Common Name.
-
If the common name is different than the Alternative name, enter the Common Name for your certificate.
Important information on common names
-
Enter the Organization associated with the certificate.
This is the full legal company or personal name. (such as Magnolia International or Frolicking Fairies)
-
If applicable, provide the Organizational Unit name.
Example: The Awesome Department
-
Enter the Locality, the full city name.
Example: Kilgarvan
-
Enter the State, the full state name.
Example: Kerry
-
Enter the Country’s two letter code.
Example: IE
-
Click Add custom certificate.
Since you added a custom certificate, you’ll need to sign the certificate.
Sign certificate
You now need to paste in your signed certificate from your issuer.
-
Go to your Cockpit and navigate to Networking > Certificates.
-
From the table, select the certificate you want to sign.
-
On the right, click the green circle with lines.
-
Click Install certificate.
-
Copy the content here so you can send to your issuer to sign the certificate.
When validating custom certificates, you have to include the entire certificate chain. Below is just an example to give you an idea on how that would look. Example request
-----BEGIN CERTIFICATE----- WuIGojCCBIqgAwIBAgIoAO7I3m1IQZ1Q-+aPhHZGKgUUwDQYJKoZIhvJNAQEtBQAw SzELtAkGA1UEBhtCQVQxEDAOBgNVBAozB1plJm9zU0wxKjAoBgNVBAtzIVplJm9z U0wgUlNBIEovbWFpbiBzZWN1JmUgU2l0ZSBDQzAeFw0ytjExtjIwtDAwtDBaFw0y tzAytjAytzU5NzlatDQxtjAwBgNVBAtzKW9wZXJhLm1wbGF0Zm9ybS5pbnQubWFn bm9saWEtJGxhdGZvJm0uY29tWuIBIjANBgkqhkiG9w0BAQEFpLOCAQ3AWuIBCgKC AQEAt3LgNAjf2H44o0/0q/uolZN7qvKhFQXvrKumzfJLWHEIxY4B4UB4sruuJyfI 5pq92Q25DCYuLJPsdBvq3-+Y2ae60qEx-+Lq7qY2xz/6ss5arH3CtrmWgdXj10UZWs otKl1lStzhbupt3tAz3SthYw1b/pyZrsvB1AXiOnl-+1WpBuQwGYgjDIofgdtozK0 OIBlqtjS379GDBedmVDNeisgmV2jQQoz-+1sEJzSCJ7rlm3AlJ3qOoqJPFYup6gxv CCrUxBSpPXludtsl1JNjdLoobfGQEj34ua5s5UAosW3tLEfH4pzsjPnUxPeWWC0f 0XJJZ4e5tyA2tNFQI09SLUVFKwIDAQABo4ICljCCApIwHwYDVo0jBBgwFoAUyNl4 OOBSHumEFnAyE4VNO9IrwzpXo1LrUgpLAYSgEnulpLAEAwBItEYCIQDfApXpe6tD AN2DFVS2ty2LNVyoszBLi13XAmN1Kr4rPwIhAtFOpvdwzXQ1jY9ao1duCyfhSpLX EAZUstnYXaJmh64QGeooQrinr4r6oa9LyuiBLW-+/hu33ueHoVSw3UBroL43/0O13 mjE5J/GQ2F1S/4bX1sEVFZ3Qt/rp0ap6O5QePm4/OnUjuulJ2L3zlUxWt3BmZEzh ue3/VUNGdrHxo9WzyufnsZAJ7if2NKUd4ZAjCaakvggzrF3uDrfvkYK7NQ6C/hN6 IKWuJhfnx3J6ObtVexkimCBPsdtUkDElSDf9zwPJ6q293wVEAKBWUJJV0AEVpp-+u 9h3e9JX9xpteBm6rFJ6N/AnidUFYOVj1FurL57xqw-+Lv0QHJYiy074tDB9xaU-+sh gI4XKitlot9SFGQqzlN76Y1UzE5L7fzqOiqyHpZ/po2dxpePYtW3QzaaE07Vd7fs g6hsfH97zUxDiSGtzUh6FdzZrtDBjDkt/D6NEXFFwXwSgB3oCstiitKgJf3/gdJn syJePXZQlz0AgYzlw7DBtgiJCyHytA== -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- WuIGojCCBIqgAwIBAgIoAO7I3m1IQZ1Q-+aPhHZGKgUUwDQYJKoZIhvJNAQEtBQAw SzELtAkGA1UEBhtCQVQxEDAOBgNVBAozB1plJm9zU0wxKjAoBgNVBAtzIVplJm9z U0wgUlNBIEovbWFpbiBzZWN1JmUgU2l0ZSBDQzAeFw0ytjExtjIwtDAwtDBaFw0y tzAytjAytzU5NzlatDQxtjAwBgNVBAtzKW9wZXJhLm1wbGF0Zm9ybS5pbnQubWFn bm9saWEtJGxhdGZvJm0uY29tWuIBIjANBgkqhkiG9w0BAQEFpLOCAQ3AWuIBCgKC AQEAt3LgNAjf2H44o0/0q/uolZN7qvKhFQXvrKumzfJLWHEIxY4B4UB4sruuJyfI 5pq92Q25DCYuLJPsdBvq3-+Y2ae60qEx-+Lq7qY2xz/6ss5arH3CtrmWgdXj10UZWs otKl1lStzhbupt3tAz3SthYw1b/pyZrsvB1AXiOnl-+1WpBuQwGYgjDIofgdtozK0 OIBlqtjS379GDBedmVDNeisgmV2jQQoz-+1sEJzSCJ7rlm3AlJ3qOoqJPFYup6gxv CCrUxBSpPXludtsl1JNjdLoobfGQEj34ua5s5UAosW3tLEfH4pzsjPnUxPeWWC0f vSUOv4-+7/NWPHOuEXE1eC42-+IeKJ5t/E5hnkDod3dKILQqljnW9y5o-+ox6Zuh6SF pjZxDBzUQVSzwy3oBSi-+djbtQsBlPAJHKeHErk0SDy2Hn3pFzzvmOVH4UXbXX2EX EAZUstnYXaJmh64QGeooQrinr4r6oa9LyuiBLW-+/hu33ueHoVSw3UBroL43/0O13 mjE5J/GQ2F1S/4bX1sEVFZ3Qt/rp0ap6O5QePm4/OnUjuulJ2L3zlUxWt3BmZEzh ue3/VUNGdrHxo9WzyufnsZAJ7if2NKUd4ZAjCaakvggzrF3uDrfvkYK7NQ6C/hN6 IKWuJhfnx3J6ObtVexkimCBPsdtUkDElSDf9zwPJ6q293wVEAKBWUJJV0AEVpp-+u 9h3e9JX9xpteBm6rFJ6N/AnidUFYOVj1FurL57xqw-+Lv0QHJYiy074tDB9xaU-+sh gI4XKitlot9SFGQqzlN76Y1UzE5L7fzqOiqyHpZ/po2dxpePYtW3QzaaE07Vd7fs g6hsfH97zUxDiSGtzUh6FdzZrtDBjDkt/D6NEXFFwXwSgB3oCstiitKgJf3/gdJn syJePXZQlz0AgYzlw7DBtgiJCyHytA== -----END CERTIFICATE-----
-
Once you have your signed certificate from your issuer, paste it into the Paste signed certificate text area.
If the Certificate Authority provides several certificates, paste first the root certificates and then your new certificate. -
Click Install certificate to complete the process.
-
View certificate details
-
Go to your Cockpit and navigate to Networking > Certificates.
-
Go to the certificate you want to view.
-
On the right, click the green circle with lines.
-
Click Certificate details.
Here, you can see important details such as:
-
Certificate hierarchy
-
Certificate type
-
Who the certificate was issued to
-
Who the certificate was issued by
-
The validity period of the certificate
-
Fingerprints such as Algorithm and key size
Create redirects
You can view redirects that you have created or add them directly yourself from the Cockpit. You must publish any changes you make to redirects.

- Important concepts
- Actions
Good to knows
-
The redirects server is a proxy server.
-
Redirects are evaluated in order of appearance when entered. The first match is accepted.
-
Any query parameters with a request are copied over in the redirect.
-
We use the Source URL to detect duplicate entries when you add a single redirect or batch import redirects (CSV).
If the redirect you enter is a duplicate, you get a
409
error code, showing the duplicate already exists. If there are any duplicates in a batch import of redirects, the entire batch is rejected. However, we notify you in the cockpit of the specific duplicate entries so you can remove them from the batch. -
Only
3xx
status codes are acceptable. Different codes affect the browser in different ways. For more, see here. -
If there is an issue with your
.csv
import when you import redirects, the dialog will inform you of what the issue so you can remedy it. -
Some applications (like Microsoft Excel) wrap quotations (
"
) around CSV lines. You need to remove those quotations if importing or adding a redirect in the Cockpit. -
You can use RE2 syntax.
RE2 Syntax examples
Regex example
https://www.example.com/0-9{2}(bar|baz)` matches
https://www.example.com/01bar
or `\https://www.example.com/14bazWildcard example
https://www.example.com/(.*)
→https://www.example.com/$1.html
redirectshttps://www.example.com/test
tohttps://www.example.com/test.html
Redirect best practices
To meet security and SEO expectations, canonicalize traffic to the https://www.*
host through this chain:
http://example.com -> https://example.com -> https://www.example.com
Key Guidelines
-
Ordering matters: Redirects are evaluated in order. Place the exact apex-host redirect above any path-preserving rules to avoid unintended behavior.
-
TLS coverage: Ensure your TLS secret covers both
example.com
andwww.example.com
in the same Ingress to avoid certificate mismatches. -
Single Ingress: Manage apex and
www
hosts in one Ingress. Delete any separate non-www Ingress resources, and define all hosts under the same TLS secret. -
Explicit 308 redirects: Use permanent
308
redirects to preserve HTTP methods. Define two rules:-
Exact apex-to-www redirect (avoids added trailing slashes).
-
Path-preserving redirect (ensures
/page
maps to/page
on the canonical host).
-
-
DNS alignment: Ensure DNS A/AAAA records for both
example.com
andwww.example.com
point to your Ingress controller.
Example Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
nginx.ingress.kubernetes.io/from-to-www-redirect: "true"
nginx.ingress.kubernetes.io/proxy-redirect-from: http://
nginx.ingress.kubernetes.io/proxy-redirect-to: https://
name: prod-ingress-example-com
namespace: prod
spec:
ingressClassName: nginx
rules:
- host: www.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: redirects-svc
port:
name: http
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: redirects-svc
port:
name: http
tls:
- hosts:
- example.com
- www.example.com
secretName: prod-ingress-example-com
Example redirect rules (308)
Source | Target | Code |
---|---|---|
308 - exact host |
||
308 - path-preserving |
https://example.com,https://www.example.com,308 (1)
https://example.com/(.*),https://www.example.com/$1,308 (2)
1 | The first rule avoids an added trailing slash on the target host. |
2 | The second rule preserves paths, for example: https://example.com/page → https://www.example.com/page . |
Redirect filters
You can see the status of a redirect under the Status column in the redirect table. You can also see whether the redirect uses RegEx or not.
-
Synced: Published redirect including any changes (if applicable).
-
Created: New redirect; unpublished.
-
Modified: Changes were made to the redirect; unpublished.
-
Deleted: The redirect is marked for deletion; it is removed the next time you publish.
-
In your Cockpit, go to Networking > Redirects.
-
Click Status.
-
From the dropdown, choose the desired statuses.
-
Click Save.
-
In your Cockpit, go to Networking > Redirects.
-
Click RegEx.
-
From the dropdown, click yes (uses RegEx) or no (does not use RegEx).
-
Click Save.
To remove the filter:
-
Click the next to the selected button.
Select desired cluster
Select your desired cluster from the dropdown menu at the top of the Cockpit.

Add redirect server
By default, redirects are served from the backend. However, you can configure the settings to suit your needs if you want to use a Frontend redirect. After adding the redirect server, you can configure and/or uninstall the server as needed. Follow the instructions here to do just that:
-
In your Cockpit, go to Networking > Redirects.
-
Click the Add redirect server button.
-
In the dialog, choose the settings that best suit your needs.
-
Choose the number of Replicas you would like. There is a minimum of 2 redirect server replicas.
You may choose as many replicas as needed. However, if no more memory is available, the system rejects new replicas.
-
Under Redirects server, choose Backend or Frontend .
If choosing Frontend, you’ll need to pass the port number you want to use, such as
3000
. -
Under Load balancing, choose Round Robin or Cookie based load balancing.
If choosing Cookie based, you’ll need to give the cookie a name. If you have sticky sessions enabled, this name must be the same as the value in the nginx.ingress.kubernetes.io/session-cookie-name
ingress annotation in yourvalues.yml
file.
-
-
Set your desired Memory limit in MB.
Memory limit detailsMemory limit specifies the maximum amount of memory (in megabytes) allocated to each redirect server instance. This setting is critical for ensuring the server performs efficiently while managing redirects, especially under varying traffic loads.
When to adjust:
-
High traffic: Add more replicas if you expect unusually high traffic volumes, as this can be memory-intensive.
-
Resource optimization: Decrease the limit for low-traffic scenarios to optimize resource usage, especially in resource-constrained environments.
-
Frontend vs. Backend: Frontend redirect servers (e.g., using a CDN or JavaScript-based redirects) may require different memory considerations compared to backend servers, as frontend redirects offload some processing to client-side resources.
Start Conservative: Begin with a moderate memory limit (e.g., 128 MB) and scale up based on observed needs. Increaseing memory is only useful if you have a large amount of rules. Consider increasing to 256 MB if you have a lot of rules. Beyond that, create more replicas.
-
-
Don’t forget to save your updates.
Configure redirect server
Once you’ve successfully added a redirect server by following the instructions in Add redirect server and saved your updates, the Add redirect server button in the Cockpit changes to Configure redirect server. Clicking this button opens a dialog where you can:
-
Edit the redirect server settings: Modify the existing configuration, such as the number of replicas, redirect server type, load balancing method, or cookie name (if applicable).
Considerations 🤔
-
Uninstall the redirect server: Remove the custom redirect server entirely, reverting to the default backend behavior.
Considerations 🤔
Add redirects
-
Go to Networking > Redirects.
-
Select the desired Environment from the dropdown list.
-
Add a single redirect or import a redirect CSV file.
-
Click Add.
-
In the dialog, fill out the following.
-
The Source URL. This is the place to redirect from.
-
The Target URL. This is the place to redirect to.
-
The Code. This is the http status code passed with the redirect. Only
3xx
http codes are acceptable. -
Check Url with regular expression if the URL provided uses RegEx.
(.*)
Why use RegEx? -
Click Add to complete the action.
-
-
Click Upload/Modify.
-
Click Choose File to import a CSV file for redirects.
formatId,Source,Target,Code,IsRegex (1)
1 Only 3xx
http codes are acceptable.Id
is optional. If anId
is provided, the system tries to match it with an existing record and update it. If blank or no match is found, a new record is created.exampleId,Source,Target,Code,IsRegex 1,https:://www.example.com/[0-9]{2}(bar%7Cbaz),https://www.example.be/barbaz.html,308,true
-
Select your file.
-
Click Upload/Modify to complete the action.
-
Manage redirects
If necessary, you can also edit or delete a redirect.
-
Go to Networking > Redirects.
-
Select the desired Cluster from the dropdown list.
-
Select the desired Environment from the dropdown list.
-
Select the redirect you want to manage.
Publish redirects
You must publish any changes you’ve made to redirects from within the Cockpit.
-
Go to Networking > Redirects.
-
Make changes as desired inside the Redirects screen.
-
Click Publish all.
-
Enter a meaningful message so it’s easier to understand what changes were made. This is useful if you need to restore changes.
-
Click Publish all.
Add secrets
Secrets are sensitive data, like passwords or tokens, stored securely for certain tasks. These secrets securely authenticate Cockpit’s network operations. For example, they can be used Ingresses. The secret types covered in this section are:
-
Opaque: Store custom credentials (e.g., API tokens).
-
Registry: Provide credentials for container registries.
-
Basic Auth: Set up HTTP Basic Authentication.
Instructions
-
Go to your Cockpit and navigate to Networking > Secrets.
-
Choose the Environment.
-
Click Add.
-
In the dialog, choose the Type of secret.
Store custom credentials (e.g., API tokens).
-
Enter the Key.
-
Enter the Value.
You may need to click the icon.
Provide credentials for container registries.
-
Enter the Domain name. For example,
registry.magnolia-platform.com
. -
Enter the User.
-
Enter the Password.
Set up HTTP Basic Authentication.
-
Enter the User.
-
Enter the Password.
-