-
Notifications
You must be signed in to change notification settings - Fork 4
Expand file tree
/
Copy path.env.example
More file actions
102 lines (95 loc) · 5.38 KB
/
Copy path.env.example
File metadata and controls
102 lines (95 loc) · 5.38 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
# ==============================================================================
# RemitX - environment setup
# Copy this file to .env and fill in each value using the steps below.
# Nothing in this file is a secret - do not commit your actual .env.
# ==============================================================================
# ------------------------------------------------------------------------------
# STEP 1 - Stellar network
# ------------------------------------------------------------------------------
# Leave these as-is for development (Stellar testnet, funded automatically via
# Friendbot when a user activates a wallet). To go live on Stellar mainnet
# later: set STELLAR_NETWORK=public and STELLAR_HORIZON_URL to a mainnet
# Horizon instance (e.g. https://horizon.stellar.org). Do not point this at
# mainnet until the escrow release-authorization design (see
# contracts/escrow/README.md) is decided and the app has been audited.
STELLAR_NETWORK=testnet
STELLAR_HORIZON_URL=https://horizon-testnet.stellar.org
# ------------------------------------------------------------------------------
# STEP 2 - Asset issuers (required for any non-XLM asset)
# ------------------------------------------------------------------------------
# XLM needs nothing - it's Stellar's native asset. Every other asset
# (USDC, EURC, or a real anchor-issued token like NGNT) is only a valid
# Stellar asset once you know which account issues it, because on Stellar an
# asset is identified by (code, issuer) together, not by code alone.
#
# How to find an issuer's public key:
# 1. For USDC on testnet: Circle publishes their testnet issuer at
# https://developers.circle.com/stablecoins/docs/usdc-on-test-networks
# 2. For any anchor's asset (e.g. a corridor-specific token): fetch the
# anchor's stellar.toml from https://<anchor-domain>/.well-known/stellar.toml
# and read the CURRENCIES section - each entry lists the issuer.
# 3. For an asset you issue yourself: it's the public key of the Stellar
# account you created and configured to issue that asset.
#
# Add one line per asset you actually support, named STELLAR_<CODE>_ISSUER.
# Sending/routing/liquidity lookups for an asset with no issuer configured
# here will fail with a clear "no configured issuer" error rather than
# silently using a placeholder.
# STELLAR_USDC_ISSUER=
# STELLAR_EURC_ISSUER=
# ------------------------------------------------------------------------------
# STEP 3 - Database (Supabase)
# ------------------------------------------------------------------------------
# The app talks to Supabase directly via @supabase/supabase-js - no ORM, no
# connection string, no IPv6/pooler headaches.
#
# 1. Create a project at https://supabase.com (or use an existing one).
# 2. Create the tables: open your project -> SQL Editor -> paste the entire
# contents of supabase-schema.sql (project root) -> Run.
# 3. Get your keys: Project Settings -> Data API (or "API" on older
# dashboards).
# - "Project URL" -> NEXT_PUBLIC_SUPABASE_URL
# - "service_role" secret -> SUPABASE_SERVICE_ROLE_KEY
# Do NOT use the "anon public" key for SUPABASE_SERVICE_ROLE_KEY - the
# service role key is the one that can actually read/write your tables
# from server-side API routes, and it must never be exposed to the
# browser (it isn't - only NEXT_PUBLIC_SUPABASE_URL is public).
NEXT_PUBLIC_SUPABASE_URL=
SUPABASE_SERVICE_ROLE_KEY=
# ------------------------------------------------------------------------------
# STEP 4 - Auth
# ------------------------------------------------------------------------------
# A random secret used to sign session JWTs. Generate one with:
# openssl rand -base64 32
# Keep this the same across deploys of the same environment - rotating it
# invalidates every existing session.
JWT_SECRET=
# ------------------------------------------------------------------------------
# STEP 5 - Cloudflare Turnstile (bot verification on login/register)
# ------------------------------------------------------------------------------
# 1. Go to https://dash.cloudflare.com/?to=/:account/turnstile
# 2. Add a site - for local dev, add "localhost" as a domain (Turnstile
# supports this directly; no need for a real domain yet).
# 3. Copy the Site Key and Secret Key it gives you.
# 4. NEXT_PUBLIC_TURNSTILE_SITE_KEY is public (shipped to the browser) -
# that's expected and safe. TURNSTILE_SECRET_KEY must stay server-only.
# Without these set, the app skips verification in development so
# `npm run dev` still works - set both before deploying anywhere real.
NEXT_PUBLIC_TURNSTILE_SITE_KEY=
TURNSTILE_SECRET_KEY=
# ------------------------------------------------------------------------------
# STEP 6 - App
# ------------------------------------------------------------------------------
# The public URL this app is served from. Use http://localhost:3000 for
# local development; set it to your real domain in production (Vercel sets
# this automatically for preview URLs, but a custom domain needs it set
# explicitly).
NEXT_PUBLIC_APP_URL=http://localhost:3000
# ------------------------------------------------------------------------------
# STEP 7 - Security
# ------------------------------------------------------------------------------
# A random secret used to sign CSRF tokens and password reset links.
# Generate one with:
# openssl rand -base64 32
# Keep this the same across deploys of the same environment.
CSRF_SECRET=