Self-hosting

#Before you start

gitpad is open source under the GNU Affero General Public License, version 3 only (AGPL-3.0-only). The source is at github.com/sachouliax/gitpad.

Running gitpad in production means holding signing keys that control other people's fees. Read Security and review the code paths you deploy. Never run integration tests against a production database: several suites truncate tables.

#Architecture

Browser + user wallet -> Web (Next.js) -> GitHub App API
                                       -> PostgreSQL
                                       -> Solana RPC -> Meteora DBC / DAMM v2
Worker -------------------------------> PostgreSQL, Solana RPC

Sources of truth: GitHub for repository identity and permission; Solana and Meteora for pools, swaps, fees, migration and settlement; PostgreSQL for workflow records and balances derived from verified evidence.

No custom Solana program is required. Fees are routed by Meteora's creator and partner fee authorities, held by the web service's protected signers.

The web service runs as a single persistent instance, because launch signing sessions keep in-memory state. The worker is a separate persistent process.

#Requirements

• Node.js 22 and npm, using the committed package-lock.json.
• PostgreSQL (the recorded tests use PostgreSQL 17).
• A Solana RPC endpoint for the intended network. A second, independent RPC is recommended for graduation and chart verification.
• A GitHub App with repository Metadata: read permission and a callback at <APP_ORIGIN>/api/github/callback.
• A Meteora DBC config account that you create and control (see below).
• For chain integration tests: a local solana-test-validator with the Meteora DBC and Metaplex program fixtures.

#Meteora DBC config

Each deployment must create its own DBC config on chain and set its address in DBC_CONFIG. A mainnet config address from another deployment does not exist on a local validator, and a config you do not control routes fees to someone else.

The launch guard checks the main on-chain settings and rejects configs that do not match:

The supply (1,000,000,000), token authority and curve shape come from the profile you use to build the config. src/launch-curve.mjs builds the reviewed curve profiles, including the 85 SOL graduation profile with the 1% builder allocation. Compare profiles offline with:

node scripts/compare-launch-curves.mjs

New pools are created with the public key of PLATFORM_CREATOR_SECRET_KEY as pool creator, and the config's fee claimer must be the public key of PLATFORM_PARTNER_SECRET_KEY. When you change DBC_CONFIG, keep every previously used config in DBC_LEGACY_CONFIGS so existing markets keep resolving.

#Environment variables

Copy the names from .env.example into an ignored .env.local for development, or into your provider's secret store for production. Secrets are server-only: never put them in a NEXT_PUBLIC_ variable.

#Core

#$GITPAD identity

Everything tied to the platform token stays hidden until GITPAD_TOKEN_MINT is set. These are public addresses, not secrets.

Hand-verified receipts (buybacks, protocol liquidity deposits, team locks) are published in data/platform-receipts.json, so every addition is a reviewable commit. The worker adds later buybacks it detects on chain.

#Rewards and allocation

#Operations and treasury

#Optional features

#Financial execution gates

Keep these disabled unless you have reviewed their separate activation requirements:

REPO_BUYBACK_EXECUTION_ENABLED=false
REPO_LIQUIDITY_EXECUTION_ENABLED=false
BUILDER_REINVEST_ENABLED=false

The related REPO_BUYBACK_*, REPO_TOKEN_MINT, REPO_TREASURY_TOKEN_ACCOUNT, REPO_LIQUIDITY_* and BUILDER_REINVEST_* variables have no default spending values. An incomplete configuration stops execution.

The worker needs database, RPC and config access, but neither signer secret. It recovers transactions that the web service already authorized and signed.

#Commands

Install and run the web app in development (it serves on port 3001):

npm ci
npm run dev

Apply database migrations:

npm run db:migrate

With a .env.local file, standalone scripts need the variables loaded explicitly:

node --env-file=.env.local ./node_modules/drizzle-kit/bin.cjs migrate --config drizzle.config.mjs

Run the worker:

# persistent worker
npm run worker

# a single cycle, for local checks
node --env-file=.env.local scripts/run-worker.mjs --once

Build and start the production web service:

npm run build
npm run start

#Tests

Checks that need no database or chain:

node scripts/compare-launch-curves.mjs
node --test tests/market-config.test.mjs tests/discovery-rules.test.mjs
git diff --check

Integration suites need a disposable PostgreSQL database and, for chain tests, a local validator with the Meteora fixtures. Examples:

npm run test:launch
npm run test:launch:chain
npm run test:trade
npm run test:fees
npm run test:claim
npm run test:discovery
npm run test:reconcile

These suites truncate tables and create local transactions with disposable in-memory keys. Some enforce a specific database name or port; keep those guards in place.

The full suite runs through one entry point that provisions every database it needs on a disposable PostgreSQL server (127.0.0.1:55432) and expects solana-test-validator on 127.0.0.1:8909 for chain suites:

node scripts/ci/run-tests.mjs

Receipt and buyback-detection tests run against real finalized transactions from the upstream deployment, preloaded from tests/fixtures/reference-platform.json by the runner.

#Release order

1. Build and test the exact revision you will deploy.
2. Check that you have a recent, restorable database backup.
3. Apply additive migrations.
4. Deploy the worker, then the web service.
5. Confirm pages respond, operator endpoints reject anonymous requests, and indexing and reconciliation succeed across existing markets.

Back up the database off-host. Payout history is part of the ledger: restoring fee evidence without settled payouts could allow duplicate payments, so restore and reconcile the complete claim ledger before enabling payouts.

#AGPL-3.0 obligations

gitpad is licensed under AGPL-3.0-only. If you run a modified version of gitpad and let users interact with it over a network, you must offer those users the complete corresponding source code of your modified version, under the same license. A link to a public repository containing your exact deployed source is a common way to do this.

• Keep the license and copyright notices.
• License your modifications under AGPL-3.0-only.
• Third-party dependencies and assets keep their own licenses.

This is a summary, not legal advice. Read the license text.