chore: remove optional backend-api service from tower-svc.yml default manifest

[mp-seqera]

Summary

The backend-api Service was included by default even though it’s only needed when a deployment intentionally exposes the backend to API/CLI users via a dedicated subdomain. Keeping it enabled by default caused confusion and could conflict with the frontend’s wildcard routing.

What changed

• Removed the backend-api Service from the default deployment manifest.

Rationale

• Avoids routing conflicts with the frontend’s wildcard setup.
• Reduces unnecessary surface area (e.g., NodePort exposure) for deployments that don’t need external API access.
• Aligns defaults with the principle of least privilege and least surprise.

Impact / Compatibility

• No impact for typical deployments that don’t use the external API.
• Deployments that relied on backend-api must re-enable it explicitly. TBD if we need to provide a separate guide for this.

Security

• Removes cluster-wide exposure by default; safer out-of-the-box posture.

[netlify]

✅ Deploy Preview for seqera-docs ready!

Name	Link
🔨 Latest commit	f66c3ed
🔍 Latest deploy log	https://app.netlify.com/projects/seqera-docs/deploys/6973bbd3d117a900083160f6
😎 Deploy Preview	https://deploy-preview-843--seqera-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[gwright99]

Asked in ticket, but I'll ask here too: "What was the benefit of exposing this API endpoint publicly in the first place? (beyond just specific subdomain control)"

[gwright99]

IMO there should be placeholder text explaining that we used to have a service there but it was removed (with a link to this issue), along with some guidance on why sites might wish to keep it around (if at all).

Let's do a favour to future us and any client doing an upgrade to help explain within the manifests why something is different rather than having to answer it one-off via support tickets.

[gavinelder]

@markpanganiban I would prefer not to remove this and instead add notes into the manifest explaining why it exists.

The historic documentation and deployment configuration should not change for customers, as they may use these manifests to restore their environment and these changes may not be transparent for them.

Complementing and explaining the configuration feels like a more appropriate approach.

Adding something like.

#
# Backend API exposes the API directly if you wish a seperate API endpoint such as api.cloud.seqera.io
# Requires additional config of the following variable.
#----

Along with something like the following.

#
# Ingress resources are evaluated on a first match & priority order basis.
# Take care when modifying. 
#----

Note - we are reworking some of these aspects and looking to add appropriate warnings and disclaimers for the examples.

An issue has been created for this work as it's out of scope for this PR.

[justinegeffen]

@bebosudo, the pre-commit is failing because of this: https://yaml.dev/doc/ruamel.yaml/api/#Duplicate_keys. The PR was opened before we introduced pre-commit and although it's not a blocker and we can merge, is there something we can do to mitigate the failing check?

[bebosudo]

@justinegeffen pre-commit is reporting an issue because this triple dash was removed, causing the two separate YAML documents (frontend deployment document and backend service document) to become a single one

while constructing a mapping
  in "platform-enterprise_versioned_docs/version-25.3/enterprise/_templates/k8s/tower-svc.yml", line 74, column 1
found duplicate key "apiVersion" with value "v1" (original value: "apps/v1")
  in "platform-enterprise_versioned_docs/version-25.3/enterprise/_templates/k8s/tower-svc.yml", line 100, column 1

unrelated to the error: if the backend API service is optional, shouldn't we comment it out?

[bebosudo]

#1058