Skip to main content
A PowerSync instance is a running deployment of the PowerSync Service: it replicates data from your source database and streams it to clients based on your Sync Streams. When self-hosting, you run the Service in your own infrastructure and configure each instance with a config file, as described below.

Configure Your Instance

A self-hosted instance needs four things before clients can sync:
  1. A connection to your source database, which PowerSync replicates data from. See Source Database Setup for preparing the database.
  2. A bucket storage database, where the PowerSync Service stores the data it prepares for syncing to clients. MongoDB and Postgres are supported.
  3. Client authentication. See Authentication Setup. When getting started, you can use temporary development tokens instead of setting up a full auth provider.
  4. A sync configuration defining what data syncs to which clients, written as Sync Streams.
You define all of these in the main config file, along with some operational settings. We recommend keeping the sync configuration in a separate file that the main config references, though it can also be defined inline. The skeleton below shows the most common options; the Configuration Reference documents all of them.
service.yaml

Example service.yaml

The config used by our self-host-demo app. Use the demo as a working reference for your own setup.

Supplying the Config File

Both YAML and JSON config files are supported. The PowerSync Service can read the config in three ways:
  1. From a config file mounted on a volume
  2. From an environment variable containing the Base64 encoding of the config file
  3. From a command line parameter (also Base64 encoded)
You can see examples of these methods in the docker-compose file of our self-host-demo app.

Environment Variable Substitution

The config file uses custom tags for environment variable substitution. !env [variable name] substitutes the value of the environment variable named [variable name]. For example, with the environment variable PS_MONGO_URI=mongodb://mongo:27017/powersync, the YAML
service.yaml
resolves to uri: mongodb://mongo:27017/powersync. Only environment variables with names starting with PS_ can be substituted.

Configuration Reference

A machine-readable JSON schema of the config file is available, published as @powersync/service-schema.
Add this comment to the top of your YAML config file to get validation and autocomplete in editors that support the YAML language server (for example VS Code with the YAML extension):
The config file supports the following top-level keys, documented in the sections below:

replication

The replication section defines the source database that PowerSync replicates data from. Specify the connection details in replication.connections. Only one connection is currently supported; multiple connection support is on our roadmap. For instructions on preparing your source database, see Source Database Setup.
If you are using hosted Supabase, you will need to enable IPv6 for Docker as per the Docker docs.If your host OS does not support Docker IPv6 (e.g. macOS), run Supabase locally instead.This is because Supabase only allows direct database connections over IPv6. PowerSync cannot connect using the connection pooler.
All connection types support these common options:
string
required
The connection type. One of postgresql, mongodb, mysql, mssql, or convex.
string
default:"default"
Unique identifier for the connection. Optional when only a single connection is present.
string
default:"default"
Additional meta tag for the connection, used for categorization or grouping.
string[]
Block connections to any of these IP ranges. Include local to block anything not in public unicast ranges.
The remaining options depend on the connection type:
service.yaml
string
Connection URI in the format postgresql://user:password@hostname:5432/database. Individual connection parameters take precedence over values in the URI.
string
Database hostname. Required if not specified in uri.
number
default:"5432"
Database port.
string
Database username. Required if not specified in uri.
string
Database password. Required if not specified in uri.
string
Database name. Required if not specified in uri.
string
default:"verify-full"
SSL mode: verify-full, verify-ca, or disable. disable is only suitable for local/private networks, not for public networks.
string
CA certificate content in PEM format. Required for verify-ca, optional for verify-full.
string
Client certificate content in PEM format, for TLS client authentication.
string
Client private key content in PEM format, for TLS client authentication.
string
Use a servername for TLS that is different from hostname.
string
default:"powersync_"
Prefix for Postgres logical replication slot names and replication stream names.
number
default:"8"
Maximum number of connections to the source database, per Service process.
number
Connection timeout in seconds. Takes precedence over a connect_timeout query parameter in the URI.
number
default:"30"
Idle timeout in seconds for snapshot connection sockets. If the storage database cannot keep up during the initial snapshot, a storage flush can stall the snapshot for longer than this timeout, which closes the source connection mid-snapshot. This appears in the Service logs as Socket timed out errors during the initial snapshot. Increase the timeout if you see these errors.
number
default:"60"
Interval in seconds between source connection heartbeats. Must be between 5 and 60.
service.yaml
string
required
Connection URI in the format mongodb:// or mongodb+srv://. Standard connection options such as connectTimeoutMS, socketTimeoutMS, serverSelectionTimeoutMS, maxPoolSize and maxIdleTimeMS can be set as query parameters in the URI.
string
Database name. Defaults to the database in the URI path.
string
Database username. Defaults to the username in the URI.
string
Database password. Defaults to the password in the URI.
string
default:"off"
Controls how change stream post-images are used: off, auto_configure, or read_only. auto_configure is recommended for new instances. See Post Images for details on each option.
number
default:"60"
Interval in seconds between source connection heartbeats. Must be between 5 and 60.
MySQL support is currently in a Beta release.
service.yaml
string
Connection URI in the format mysql://user:password@hostname:3306/database. Individual connection parameters take precedence over values in the URI.
string
Database hostname. Required if not specified in uri.
number
default:"3306"
Database port.
string
Database username. Required if not specified in uri.
string
Database password. Required if not specified in uri.
string
Database name. Required if not specified in uri.
number
default:"1"
Server ID used when connecting as a replication client.
string
CA certificate content in PEM format.
string
Client certificate content in PEM format, for TLS client authentication.
string
Client private key content in PEM format, for TLS client authentication.
number
default:"50"
The combined size in MB of binlog events that can be queued in memory before throttling is applied.
SQL Server support is currently in a Beta release. Also see SQL Server Additional Configuration.
service.yaml
string
Connection URI in the format mssql://user:password@hostname:1433/database. Individual connection parameters take precedence over values in the URI.
string
Database hostname. Required if not specified in uri.
number
default:"1433"
Database port.
string
Database username. Required if not specified in uri or authentication.
string
Database password. Required if not specified in uri or authentication.
string
Database name. Required if not specified in uri.
string
The database schema to replicate from.
string
CA certificate content in PEM format.
string
Use a servername for TLS that is different from hostname.
object
Alternative authentication configuration, instead of username and password.
object
Additional replication settings.
number
default:"60"
Interval in seconds between source connection heartbeats. Must be between 5 and 60.
The Convex replicator is currently released as an experimental feature. See Convex source database setup.
service.yaml
string
required
The URL of your Convex deployment.
string
required
A deploy key for the Convex deployment, used to authenticate against the Convex Streaming Export API.
number
default:"1000"
Interval in milliseconds between polling for new changes.
number
default:"60000"
Timeout in milliseconds for requests to the Convex API.

storage

The PowerSync Service requires a storage database to store the data and metadata for buckets. You can use either MongoDB or Postgres for this purpose.
The bucket storage database is separate from your source database.
string
required
The storage backend type: mongodb or postgresql.
number
default:"8"
Maximum number of connections to the storage database, per Service process.
string[]
Block connections to any of these IP ranges. Include local to block anything not in public unicast ranges.
number
default:"2"
Storage version to use when deploying a sync configuration that does not specify a storage version. You typically do not need to change this. See Storage Version for the available versions and how they interact with the sync configuration’s storage_version field.

MongoDB Storage

service.yaml
string
required
Connection URI in the format mongodb:// or mongodb+srv://. Standard connection options such as connectTimeoutMS, socketTimeoutMS, serverSelectionTimeoutMS, maxPoolSize and maxIdleTimeMS can be set as query parameters in the URI.
string
Database name. Defaults to the database in the URI path.
string
Database username. Defaults to the username in the URI. See Required Permissions for the roles the user needs.
string
Database password. Defaults to the password in the URI.
number
default:"0.2"
Throttles the clearing of old bucket data after deploying a new sync configuration, by pausing between batches. The pause is proportional to the previous batch duration. Increase this to reduce the impact of clear operations on the storage cluster, or use 0 to clear as fast as possible. Must be between 0 and 20.
string
Read preference for bulk checksum and bucket data reads: primary, primaryPreferred, secondary, secondaryPreferred, or nearest. If unset, MongoDB driver defaults are used. This is an experimental option and may be removed in a future release.
object
Experimental support for storing large bucket data chunks in S3-compatible object storage instead of MongoDB.
Required Permissions
The Service creates and manages all collections and indexes in the storage database itself, so no manual schema setup is needed. When authentication is enabled, the user needs the built-in readWrite and dbAdmin roles on the storage database:
No access beyond the storage database is required. The readWrite role covers regular operation, including creating and dropping collections and indexes. The dbAdmin role is additionally required for collecting storage size metrics and for dropping the database when an instance is torn down. Create the user with:
MongoDB authenticates against the database where the user was created, so creating the user in the storage database itself works with the connection URI shown above. If you create the user in a different database, such as admin, add authSource=admin to the connection URI. On MongoDB Atlas, assign the same two roles restricted to the storage database.
Replica Set Requirement
MongoDB requires at least one replica set node. A single node is fine for development/staging environments, but a 3-node replica set is recommended for production deployments. MongoDB Atlas enables replica sets by default for new clusters. However, if you’re using your own environment you can enable this manually by running:
If you are rolling your own Docker environment, you can include this init script in your docker-compose file to configure a replica set as once-off operation:
docker-compose.yaml

Postgres Storage

You can use Postgres as an alternative bucket storage database.
service.yaml
Postgres storage accepts the same connection options as a Postgres replication connection: uri, hostname, port, username, password, database, sslmode, cacert, client_certificate, client_private_key, tls_servername, slot_name_prefix and connect_timeout. In addition, batch limits can be tuned:
object
Limits for batch operations during replication. Increasing these limits can improve replication performance, at the cost of higher memory usage.
Database Setup
You’ll need to create a dedicated user and schema for PowerSync bucket storage. You can either:
  1. Let PowerSync create the schema (recommended):
  1. Or manually create the schema:
A demo app with Postgres bucket storage is available here.
Postgres Version Requirements
Separate Postgres servers are required for replication connections (i.e. source database) and bucket storage if using Postgres versions below 14.

port

The port setting determines where clients and tools connect to your instance. Change it if the default conflicts with another service in your deployment.
number
default:"8080"
The port on which the PowerSync API server will listen for connections. Can be specified as a number or string.

sync_config

The sync_config section points the Service at your Sync Streams (or legacy Sync Rules) definition, usually a separate file referenced with path:
string
Path to the sync configuration YAML file. Ensure the file is available at that path, e.g. in the same directory as your main config or on a mounted volume.
string
The sync configuration inline as a string, as an alternative to path.
boolean
default:"true"
Whether to exit the process if there is an error parsing the sync configuration.
The top-level sync_rules key is a deprecated alias for sync_config. Use sync_config in new configurations.

client_auth

The client_auth section defines how the Service verifies your app’s users when they connect to sync. Clients authenticate with JWTs, which the Service validates using the settings here. For more details, see Client Authentication.
service.yaml
string | string[]
URI or array of URIs pointing to JWKS endpoints, used to fetch public keys for JWT verification.
object
Inline JWKS configuration, as an alternative or in addition to jwks_uri.
boolean
default:"false"
Enables Supabase authentication integration. JWKS details are derived from the Supabase connection. See Supabase Auth.
string
Legacy JWT secret for Supabase authentication (HS256 shared secret).
string[]
Valid audiences for JWT validation.
string[]
IP ranges to reject when resolving JWKS URIs. Include local to block anything not in public unicast ranges.
For production environments, we recommend using JWKS with asymmetric keys (RS256, EdDSA, or ECDSA) rather than shared secrets (HS256). Asymmetric keys provide better security through public/private key separation and easier key rotation. See Custom Authentication for more details.

api

The api section protects the Service’s admin API routes with access tokens, and sets limits that protect the Service from excessive load. Configure tokens if you use the PowerSync CLI against this instance; the limits rarely need changing.
string[]
Access tokens for the Service’s admin API routes, provided by clients as a Bearer token. If no tokens are configured, the admin API routes reject all requests.
object
Performance and safety parameters for the API.

telemetry

The telemetry section controls the operational metrics the Service shares with PowerSync and exposes for your own monitoring. See Usage Reporting and Monitoring for details.
boolean
required
When true, disables sharing of anonymized usage metrics with the PowerSync telemetry service.
number
Port on which Prometheus metrics will be exposed. When set, metrics will be available on this port for scraping.

healthcheck

Configures how health check status is exposed. See Health Checks for details on the available probes and endpoints.
object
Mechanisms for exposing health check data. If this is not configured, the Service defaults to legacy behavior for backwards compatibility (filesystem probes always enabled, plus HTTP probes depending on the Service mode). When probes is configured, each mechanism requires explicit opt-in.

migrations

The migrations section controls whether the Service updates its bucket storage database schema automatically when a new version starts up. Most deployments can keep the default automatic behavior.
boolean
default:"false"
When true, disables automatic storage database schema migrations on startup. Migrations can then be triggered externally by altering the container command.

system

The system section configures how the Service itself runs. Currently this covers logging.
object
Service logging configuration.

metadata

Use metadata to attach custom labels to an instance, for example to tell your staging and production deployments apart in error reports.
object
Custom key-value pairs (string values) that identify this instance. When error reporting to Sentry is enabled by setting the SENTRY_DSN environment variable, these pairs are attached as tags to reported errors.
service.yaml