Self-Hosting

On syncvotes.com, every party and every DAO is hosted on our validator, and the app co-signs every contract. So our validator holds every DAO, private ones included, and every ballot, secret ones included. You do not have to use our site: SyncVotes is open source, and you can run it on a validator of your own. Then your validator holds your DAOs, and ours never sees them.

Hosted by Us or Your Own

	syncvotes.com	Your own validator
Who can read private DAOs and secret ballots	Our validator’s operator	Your validator’s operator, that is you
Traffic cost	Lower: SyncVotes is a featured app, and its app rewards pay back part of the traffic	The full network price, unless your deployment earns app rewards of its own
Upkeep	None	A validator, a server, updates and backups are yours to run
Keys, parties and DAOs	Made here	Made on your site; nothing moves over from ours

Most communities are fine with our site: members still cannot read a private DAO they are not in, and a secret ballot stays hidden from other members. Self-host when it matters that no outside operator can read your DAOs at all.

What You Need

• A Splice validator on the network you want (MainNet, TestNet or DevNet), onboarded and able to buy traffic. See the validator guides on docs.canton.network.
• A Linux server for that validator with Docker, and a domain for the site.
• The code: github.com/SYNCVOTES/syncvotes.

Set It Up

1. Settings. Copy .env.example to <network>.env and fill it in: your domain (APP_DOMAIN), the server’s address, the network’s Scan (SCAN_URL), your validator’s party hint (WALLET_USER_NAME), and long random values for every secret. Set NETWORKS to your own site only.
2. Sign-in for the ledger. The app, its backend and your validator trust one Keycloak realm, which the app’s compose file brings. Start Keycloak and Caddy first (docker compose --env-file <network>.env up -d keycloak caddy), then point your validator’s .env at the realm, https://<your domain>/auth/realms/canton (AUTH_URL, AUTH_JWKS_URL, AUTH_WELLKNOWN_URL, the audiences and client ids), and restart the validator.
3. The app’s party and ledger user. Run scripts/setup-participant.mjs as its header describes. It makes the app’s own party, syncvotes-app-provider, and the app’s ledger user with the rights it needs, and prints the party id. Put it in PROVIDER_PARTY, and your validator’s own party in PAYEE_PARTY.
4. Start the app. docker compose --env-file <network>.env build, then up -d. The app uploads its Daml package at startup; https://<your domain>/version then names the package it runs.
5. Who pays. For a community of your own, BILLING_FACTOR=0 lets your validator pay all traffic, so members never top up. Keep INVITE_CODES set so only your people can sign up.

The details of every setting, the proxy options and how updates work are in the repository’s README, under Run Your Own.

After It Runs

• Members create new keys and parties on your site. A party made on syncvotes.com stays hosted on our validator; use a fresh key for yours.
• DAOs do not move between sites. Create the DAO again on yours and add the members there.
• Keep the package name syncvotes and take our releases as they come: each is an upgrade of the last, so your contracts carry over.

What the app can and cannot do on any site is in Trust Model; the validator and party are in the Glossary.