Skip to main content
Fireworks lets you fine-tune models while keeping your data and sensitive components under your control. Across every training surface, one principle holds: your training data is never used to train Fireworks-owned or shared models. This page covers training. Inference follows Zero Data Retention by default — prompts and generations are never written to persistent storage — so we focus here on the training lifecycle: where your data lives while you train, what Fireworks retains afterward (checkpoints and traces), and the controls you have to delete it. Use it to:
  • Understand how each training surface handles your data.
  • Choose the surface that fits your data-privacy requirements.
  • Know exactly what is retained, what is not, and how to delete it.

Choosing a training surface

Fireworks offers three ways to train, differing mainly in where your training data lives:
For the strictest data governance, use BYOB (keep the dataset in your own bucket) or the Training API (no dataset is ever uploaded to or stored on Fireworks).

Data retention by surface

When training runs on Fireworks-managed storage, training data is stored in Google Cloud Storage (GCS) with only a reference link retained in our database. Customers control deletion of their own datasets.

Managed Training

Retention behavior depends on the job type:

Training API

The Training API works differently: you write the training loop in your own environment, load and tokenize data locally, and send tokenized Datum batches to Fireworks GPUs on each forward_backward call. What this means for your data:
  • No dataset upload step and no dataset file stored on Fireworks’ side. Fireworks never receives your raw JSONL, and for RL or distillation the trainer never sees raw prompt text.
  • The trainer does receive the training content — as tokenized Datum batches on every forward_backward call. Those tokens are your data; they are processed transiently for the gradient step and are not retained as a dataset.
What Fireworks does retain is minimal and deletable on request:
  • Checkpoints — retained for 30 days (deletable earlier on request) so you can restart jobs without losing work.
  • Traces / logs — retained for 30 days (deletable earlier on request) so you can evaluate job performance and improve your training.
This barebones retention is by design: it keeps the product easy to use — retrieve checkpoints to restart jobs, and inspect traces to understand and improve training — while your training data is never uploaded or stored as a dataset on Fireworks.

How Fireworks accesses your cloud

Both BYOB and CMEK work by granting a Fireworks identity least-privilege access to a resource in your account — a storage bucket for BYOB, a KMS key for CMEK. Fireworks authenticates as a Google-issued OIDC identity, and you configure your cloud’s IAM to trust it. Three properties follow:
  • No long-lived secrets. Fireworks presents a short-lived, automatically rotated token on each call. There is no API key or client secret for you to store, rotate, or risk leaking.
  • Nothing runs in your cloud. Fireworks does not deploy software into your account — it calls your cloud’s API from Fireworks infrastructure, as the identity you authorized.
  • Scoped to your account. The token carries your Fireworks account ID as its audience, and you configure your trust to accept only that audience. A token issued for any other Fireworks account is rejected by your own infrastructure, not just by Fireworks.
Where federation applies, you pin trust on these values:
BYOB and CMEK authenticate as different Fireworks service accounts, so their subject identifiers differ — don’t reuse one for the other. Two cases don’t use this pattern: GCS BYOB grants access to Fireworks service account emails directly, with no token audience to scope, and Azure BYOB uses the fixed api://AzureADTokenExchange audience. Each setup page states which applies.

Two independent controls

BYOB and CMEK address different needs and can be used separately or together: CMEK covers artifacts on Fireworks-managed storage, so it complements rather than replaces BYOB. For the strictest governance, combine BYOB with secure RFT, or use the Training API, where no dataset is stored at all.

Inference

Inference at Fireworks follows Zero Data Retention by default: prompts and generations exist only in volatile memory for the duration of the request and are never written to persistent storage or used to train any model. For full details, including the Response API storage exception and how to opt out, see the Zero Data Retention policy.

Customer controls

The following controls are available for training workloads: For inference-side controls — disabling Response API storage (store=False) or deleting a specific response — see the Zero Data Retention policy.

Zero Data Retention

How Fireworks handles inference data by default

Customer-Managed Encryption Keys (CMEK)

Encrypt managed fine-tuning data with your own KMS key

Data Security Overview

Learn about our comprehensive security measures

Reinforcement Fine Tuning

Full guide to reinforcement fine-tuning

Training API

Custom training loops that keep your data on your side