Azure Marketplace

Deploy dsynct on AKS via the Azure Marketplace offering.

The dsynct Azure Marketplace offering packages dsynct as an Azure Kubernetes Service (AKS) marketplace application. One-click deploy provisions a Web-API instance and, optionally, a number of dynamic worker node pods that register with it. Once the deployment is up, all further configuration -- starting syncs, attaching to Temporal flows, adding/removing workers, running test transformations -- happens through the Web-API browser UI.

What gets deployed

The offering installs the following workloads into your AKS cluster as a cluster extension:

• web-api (1 replica) -- runs the dsynct web-api process and exposes the web UI plus the node coordinator API on port 8080. Exposed either as a public LoadBalancer (external IP) or ClusterIP (internal-only, use kubectl port-forward).

• node (0..N replicas; default 0) -- runs dsynct as a long-running node process that polls the in-cluster web-api as its coordinator. Each replica becomes a row in the Web-API's Workers section, where workers can be added or removed without restarting any pods.

• temporal (StatefulSet, 1 replica, optional) -- a single-pod temporalio/temporal dev server backed by SQLite on a persistent volume. Only deployed when you do not supply an existing external Temporal endpoint.

If Number of node workers is 0, no node pods are created. The web-api can still run Local Syncs and use the Tools section for testing -- this is the recommended starting configuration for evaluations and small projects.

Configuration fields

In addition to the usual AKS cluster parameters (VM size, count, Kubernetes version, OS SKU, auto-scaling, etc.) when creating a new cluster, the Azure Portal UI exposes the following dsynct-specific fields under Application Details:

Field	Description
Number of node workers	Number of dsynct node worker pods (0-10; default 0). Each pod registers as a separate node and can manage one or more dynamic workers. Zero is valid -- the web-api can execute syncs locally.
External Temporal host:port (optional)	host:port of an existing Temporal frontend (e.g. my-temporal.example.com:7233). Leave empty to deploy an in-cluster single-pod dev Temporal.
Web API service type	LoadBalancer exposes the web UI on a public IP. ClusterIP keeps it internal (use kubectl port-forward).
Image tag	Tag of the markadiom/dsynct image to deploy.
Temporal storage performance tier	Storage class for the in-cluster Temporal SQLite database: Standard SSD, Premium SSD, or Premium SSD v2. Premium is recommended for production workloads (~10x more IOPS). Only shown when no external Temporal is supplied.
Temporal storage size	Disk capacity for the in-cluster Temporal SQLite database (5/10/50/100 GiB). Only shown when no external Temporal is supplied.
Container resources	CPU and memory requests and limits applied to every pod, configured as four separate fields (CPU request, memory request, CPU limit, memory limit). Defaults: 1000m/512Mi request, 2000m/1024Mi limit.
OpenTelemetry collector endpoint (optional)	gRPC OTLP endpoint for log/metric export (e.g. http://otel-collector:4317). Leave empty to disable OTel.
Enable shared config volume	Provisions an Azure Files share (ReadWriteMany) mounted read-only at /etc/dsynct on the web-api pod and every node pod. Upload transformer YAML configs and other files post-deploy via the Azure Portal -- no rebuild or redeploy needed.
Shared volume size	Capacity of the Azure Files share (1/5/10/50/100 GiB). Only shown when the shared volume is enabled.

After deploying

Find the web-api address

The Kubernetes resources are named after the Cluster extension resource name you chose during deployment. In the snippets below, replace <extension-name> with that value.

If you chose LoadBalancer, watch for the external IP to be assigned:

kubectl get service webapi-<extension-name> -w

Then open http://<EXTERNAL-IP>:8080/ in your browser.

If you chose ClusterIP, port-forward to access the UI from your laptop:

kubectl port-forward svc/webapi-<extension-name> 8080:8080

Then open http://localhost:8080/.

Drive the deployment from the UI

The browser UI contains everything you need to operate the deployment. See the Web-API page for full details. In short:

• Progress -- live progress for any sync that the web-api is tracking, with controls to pause/unpause/terminate where applicable.

• Syncs -- start a Local Sync (runs inside the web-api pod) or kick off a Temporal flow, and attach to existing flows by workflow ID.

• Workers -- visible only when Temporal is configured. Lists each node pod and lets you add or remove dynamic workers across all nodes or per-node from the UI. To add more node pods, update the deployment from the Azure Portal and increase Number of node workers (see Scaling); the new pods will appear automatically once they poll the coordinator.

• Tools -- Transform Studio (test transformer YAML against sample documents) and Sync Tester (do a small ID-bounded test sync, or compare specific IDs between source and destination).

Editing the shared config volume

When Enable shared config volume is on, the deployment creates a PersistentVolumeClaim named shared-<extension-name> backed by an Azure Files share (ReadWriteMany). The share is mounted read-only at /etc/dsynct on the web-api pod and every node pod, so you can reference files like transformer configs as /etc/dsynct/transform.yaml from any flag that takes a path.

You can populate or edit files in the share at any time without redeploying. First find the storage account backing the PVC:

kubectl get pv $(kubectl get pvc shared-<extension-name> -o jsonpath='{.spec.volumeName}') \
  -o jsonpath='{.spec.csi.volumeAttributes.storageAccount}'

Then use the Azure Portal (Storage Accounts -> File shares), az storage file upload, azcopy, or an SMB mount from your laptop to drop files in. Every pod sees the change immediately. If a process reads a config file only at startup, restart the pods to pick up changes:

kubectl rollout restart deploy/webapi-<extension-name>
# Only if Number of node workers > 0:
kubectl rollout restart deploy/node-<extension-name>

Bringing your own Temporal

If you already operate a Temporal cluster, fill in the External Temporal host:port field with its endpoint (e.g. my-temporal.example.com:7233). The offering will skip deploying the in-cluster Temporal sidecar and point both the web-api and every node pod at your existing endpoint. Make sure the AKS cluster has network connectivity (and any required TLS/auth) to that Temporal frontend.

When External Temporal host:port is left empty, an in-cluster dev Temporal is deployed for convenience. This is not suitable for production -- use it for evaluations and demos only, and bring your own Temporal for any real workload.

Observability

Set the OpenTelemetry collector endpoint field to the gRPC OTLP endpoint of any collector reachable from the cluster (e.g. http://otel-collector:4317) to enable metric and trace export. Leave it empty to disable OTel entirely. See Observability for details on the metrics and traces emitted by dsynct.

Scaling

The offering is deployed as an AKS cluster extension. To change configuration after the initial install (for example, to add or remove node worker pods), update the extension from the Azure Portal:

1. Open your AKS cluster in the Azure Portal.

2. Go to Settings -> Extensions + applications.

3. Select the dsynct extension and click Update.

4. Adjust Number of node workers (or any other field) and apply.

You can also update the extension from the command line with az k8s-extension update. New node pods register with the web-api on their next poll interval (default 10s); existing dynamic workers continue running uninterrupted. Use the Workers section in the UI to launch additional workers on the new nodes.

Uninstalling

Remove the deployment from the Azure Portal:

1. Open your AKS cluster in the Azure Portal.

2. Go to Settings -> Extensions + applications.

3. Select the dsynct extension and click Uninstall.

You can also remove it from the command line with az k8s-extension delete.

Persistent volumes (the in-cluster Temporal database and any Azure Files share) follow the StorageClass's reclaim policy and may outlive the extension. If you want the underlying data removed, delete the PVCs explicitly with kubectl or remove the storage account from the Azure Portal afterwards.