Announcing Fastly Operator

We’re excited to announce our latest open source project: Fastly Operator!

Fastly Operator is a Kubernetes operator that makes it easier to use Custom TLS Certificates within Fastly. It acts as the glue between cert-manager and Fastly, allowing you to define your TLS certificates in Kubernetes and keep them synchronized to Fastly.

To start, the implementation is limited to managing Custom TLS Certificates. We may add additional custom resources and controllers in the future if they align with the project’s overall goal of bridging the gap between Kubernetes and Fastly.

If you are a Fastly customer, you’re able to use Fastly Operator!

Custom TLS Certificates

Unlike Fastly TLS Subscriptions, where you delegate the certificate details and control to Fastly, Custom TLS Certificates let you own the certificate details and push them to Fastly.

The API for Custom TLS Certificates helps you manage:

• private keys
• certificate details
• TLS activations

The challenge is that any automation to leverage Custom TLS Certificates is left as an exercise for the reader.

Our solution takes care of all this for you so that you don’t need to implement any of the fairly complex logic needed to keep multiple certificates synchronized to Fastly.

Architecture

Fastly Operator aims to provide value without reinventing any wheels.

Since cert-manager is already the standard approach for managing certificates on Kubernetes clusters, we choose to build on top of it.

Depicted below is the high level architecture of where our solution sits in the overall stack:

Custom Resource

The operator defines and reconciles a new custom resource: FastlyCertificateSync. Instances of FastlyCertificateSync point to existing TLS certificates and provide the instructions for how to sync to Fastly.

Here is an example resource:

1
2
3
4
5
6
7
8
9
10

apiVersion: platform.seatgeek.io/v1alpha1
kind: FastlyCertificateSync
metadata:
  name: example-cert-sync
  namespace: default
spec:
  certificateName: example-cert
  tlsConfigurationIds:
  - "your-fastly-tls-config-id-1"  # Replace with your actual TLS configuration ID
  - "your-fastly-tls-config-id-2"  # Optional: activate against multiple TLS configurations

Flow

In the above example, we will look for the Certificate of name: example-cert in the same namespace as the FastlyCertificateSync.

The following actions will be performed:

• upload private key from the certificate’s secret
• upload certificate details
• activate each of the certificate’s domains against the provided TLS configurations
• clear unused private keys

When certificates renew during their renewal window, we’ll pick up on the updated details and ensure that the latest values are pushed to Fastly. This operation is seamless and involves zero downtime on Fastly’s end.

Status Updates

When reconciling FastlyCertificateSync resources, we’ll reflect state changes via the status field on the resource. The status.conditions will include information reflecting each state transition:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

status:
  conditions:
  - lastTransitionTime: "2025-07-29T12:52:26Z"
    message: Private key has been successfully uploaded to Fastly
    reason: PrivateKeyUploaded
    status: "True"
    type: PrivateKeyReady
  - lastTransitionTime: "2025-07-29T12:52:26Z"
    message: Certificate is up-to-date and synced with Fastly
    reason: CertificateSynced
    status: "True"
    type: CertificateReady
  - lastTransitionTime: "2025-07-29T12:52:26Z"
    message: All TLS activations are properly configured
    reason: TLSActivationsSynced
    status: "True"
    type: TLSActivationReady
  - lastTransitionTime: "2025-07-29T12:52:26Z"
    message: No unused private keys found
    reason: NoCleanupNeeded
    status: "False"
    type: CleanupRequired
  - lastTransitionTime: "2025-07-29T12:52:26Z"
    message: FastlyCertificateSync is ready and all components are synchronized
    reason: FastlySyncComplete
    status: "True"
    type: Ready

Why we built Fastly Operator

ACME Contention

When creating certificates, the Certificate Authority (also referred to as Issuer in cert-manager) will need to perform what is called ACME validation.

This is a process that proves to the CA that you own the domain that the certificate is being created for.

Some systems like cert-manager will integrate with your DNS provider and create the record for you. Other systems like Fastly will tell you about the record that needs to be created and expect you to create it yourself. This can be problematic if you are creating certificates for a single domain in multiple systems. For us at SeatGeek, we use cert-manager to create TLS certificates for termination in our API Gateway layer. Additionally, we were asking Fastly to create certificates in their system so that we could terminate TLS at the edge.

When certificates are renewed (typically every 2 months), the ACME challenge process takes place. Each system requires a DNS record at the same location, but with different values. So, we experienced a challenge where we would have to manually update dns records for each verified domain each time either of the two systems needed to solve the ACME challenge. Not only was this not automated, but in the absence of proper observability - it was all to easy to accidentally let a certificate expire.

Below is a rough diagram of cert-manager and Fastly competing for the _acme-challenge.seatgeek.com record:

Consolidating certificate management

The idea here is simple - if we were to consolidate all of our certificate management under one system, we would be able to categorically remove the issue described above.

For us, this meant continuing to use cert-manager to manage all certificates within Kubernetes. We’d then shift from using Fastly’s TLS Subscriptions over to Custom TLS Certificates. We then created automation to take cert-manager certificates and upload them to Fastly.

Initially, this solution was built internally using proprietary closed-source systems. After running without issue for ~6 months, we demo’d this solution to Fastly and mutually agreed that other Fastly customers might be able to take advantage of this automation.

Fastly Operator was then born! We rebuilt our automation from the ground up as an open source project, and then validated the new solution internally. SeatGeek now uses Fastly Operator to manage all of our TLS certificates in Fastly.

Open Source

We are hoping that others are able to benefit from this work!

We welcome suggestions, improvements, and fixes to the solution and are interested to see how this project evolves over time.

Please don’t hesitate to create an issue or pull request on the Fastly Operator repository!