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

[markpanganiban]

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	f75b88e
🔍 Latest deploy log	https://app.netlify.com/projects/seqera-docs/deploys/6943bea389fc24000818a3c1
😎 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.