Skip to main content

Service Configuration Reference

The Flyte runs service configuration manages the lifecycle of workflow executions, background scheduling, and project environments. Defined in runs/config/config.go, the Config struct serves as the central registry for server settings, database tuning, and storage backend integration.

Server and Connectivity​

The ServerConfig defines the network identity of the runs service. It specifies the host and port for the HTTP server, which hosts multiple ConnectRPC handlers including the RunService, TaskService, and TriggerService.

type ServerConfig struct {
	Port int    `json:"port" pflag:",Port to bind the HTTP server"`
	Host string `json:"host" pflag:",Host to bind the HTTP server"`
}

In addition to its own binding, the service requires the ActionsServiceURL to communicate with the Flyte actions service for enqueuing execution tasks. As seen in runs/setup.go, this URL is used to initialize the ActionsServiceClient:

actionsClient := actionsconnect.NewActionsServiceClient(
    http.DefaultClient,
    cfg.ActionsServiceURL,
    connect.WithInterceptors(otelInterceptor),
)

Data Management and Storage​

The StoragePrefix is a critical setting that determines where Flyte stores run-related data, such as inputs and outputs. It must be a valid URI (e.g., s3://my-bucket, gs://my-bucket, or file:///tmp/flyte/data).

This prefix is passed to the RunService during initialization in runs/setup.go:

runsSvc := service.NewRunService(
    repo, 
    actionsClient, 
    dataProxyClient, 
    projectClient, 
    cfg.StoragePrefix, 
    sc.DataStore, 
    abortReconciler,
)

The WatchBufferSize parameter controls the internal memory allocated for streaming run updates. This ensures that high-frequency status changes do not overwhelm the service's event-watching mechanisms.

Project and Domain Environment​

Flyte distinguishes between persisted project data and runtime environment metadata.

Project Seeding​

The SeedProjects list allows administrators to define a set of projects that are automatically created in the database at startup if they do not already exist. This is handled by the seedProjects function in runs/setup.go, which iterates through the list and calls projectRepo.CreateProject.

Runtime Domains​

Unlike projects, domains are not stored in the database. Instead, they are defined via DomainConfig and injected into project responses at runtime.

type DomainConfig struct {
	ID   string `json:"id"`
	Name string `name:"name"`
}

In runs/setup.go, these configurations are mapped to projectpb.Domain objects and provided to the ProjectService. This design allows for global environment changes (e.g., adding a "staging" domain) across all projects simply by updating the configuration file, without requiring database migrations.

Trigger Scheduler Tuning​

The TriggerSchedulerConfig controls the background worker responsible for executing cron-based triggers. This worker is essential for automated workflow execution.

type TriggerSchedulerConfig struct {
	Enabled               bool          `json:"enabled" pflag:",Enable the trigger scheduler worker"`
	ResyncInterval        time.Duration `json:"resyncInterval" pflag:",How often to resync active triggers from the database"`
	MaxCatchupRunsPerLoop int           `json:"maxCatchupRunsPerLoop" pflag:",Maximum catchup runs fired per resync loop"`
	ExecutionQPS          float64       `json:"executionQps" pflag:",Rate limit for CreateRun calls (requests per second)"`
	ExecutionBurst        int           `json:"executionBurst" pflag:",Burst size for CreateRun rate limiter"`
}

Rate Limiting and Throughput​

The scheduler uses a token-bucket rate limiter (configured via ExecutionQPS and ExecutionBurst) to throttle CreateRun calls. This protects the runs service and the underlying database from spikes in activity when multiple cron jobs align at the same timestamp.

Resync and Catchup Logic​

The ResyncInterval determines how frequently the worker queries the database for new or updated triggers. During the bootstrap phase (implemented in runs/scheduler/start.go), the scheduler uses MaxCatchupRunsPerLoop to limit how many missed executions it attempts to fire for a given trigger. This prevents a "thundering herd" effect if the service has been offline for an extended period.

// From runs/scheduler/start.go
sched.CatchupAll(ctx, triggers, time.Now().UTC(), cfg.MaxCatchupRunsPerLoop)