Environment Variables Guide

1. Open the email you received from Own Your Website after purchase. Check your spam folder if it has not arrived.
2. Copy the license values supplied with your project, using the exact names listed above. LICENSE_KEY is your purchased key; LICENSE_PRODUCT identifies your product. Use the supplied server URL and server secret only where your project requires them.
3. Open your hosting project's environment-variable settings. Paste each supplied value without surrounding quotes. Select the intended environment, save, and redeploy.
4. Do not invent a license-server secret or reuse an authentication secret for it. Contact support if required delivery values are missing or you need to move your license to another production domain.

Screenshots restored from the original guide. Provider interfaces may change; use the written instructions and your selected project's variable names if an older screenshot differs. Never share real credentials in screenshots.

1. Go to neon.tech and sign up. Click Create Project and enter your website name.
2. Postgres version: select a version supported by your project. Keep the provider default if your project does not specify one.
3. Region: choose the region closest to your application servers or functions. For example, US East (N. Virginia) for a US deployment, or Frankfurt for a nearby European deployment. Keeping the database and server close reduces latency.
4. Backend Services / Authentication: the released Prisma templates have their own authentication, so you do not need to enable Neon Auth. For a custom website, follow its project instructions.
5. Click Create Project, then open Connect (or Connect your app manually). Select the database, role, and branch you intend to use.
6. Turn Connection pooling ON. Copy the provider-issued connection string into DATABASE_URL.
7. For the same database, branch, role, and schema, turn Connection pooling OFF and copy the direct string into DIRECT_URL or DATABASE_URL_UNPOOLED, according to your project. E-commerce uses the latter; Taxi and Business Landing use the former. Do not put a pooled URL in the direct field or create the direct URL by editing its hostname.
8. Create a separate branch or database for previews/testing. Copy its own pooled and direct URLs into that hosting environment, not Production.
9. Cold-start troubleshooting: a sleeping database can delay the first connection. Check your provider's current Prisma guidance for connection timeouts and pooling parameters; preserve its SSL settings. Do not append duplicate query separators or assume a URL rewrite will fix every connection error.
10. The three released Prisma templates apply migrations and create missing baseline CMS data during the build. No manual seed or database reset is needed. Custom projects use their own documented build and migration commands.

Screenshots restored from the original guide. Provider interfaces may change; use the written instructions and your selected project's variable names if an older screenshot differs. Never share real credentials in screenshots.

1. Generate a separate cryptographically random secret for each authentication boundary listed above. Use the Env Builder's local Generate button for supported template fields, or run openssl rand -base64 32 in your own terminal.
2. Copy the result into the matching server-only variable: NEXTAUTH_SECRET, JWT_SECRET, or another name explicitly used by your project. Do not ask a chatbot to create secrets, use a memorable phrase, or reuse the license-server secret.
3. Save the value in your hosting project's environment settings. Use different values for testing and Production, then redeploy. Changing a session secret can sign existing users out.
4. If your project uses NEXTAUTH_URL, set it to the exact application origin as described in Site URLs, not to an API callback path.

Screenshots restored from the original guide. Provider interfaces may change; use the written instructions and your selected project's variable names if an older screenshot differs. Never share real credentials in screenshots.

1. For local testing, use your actual local origin, such as http://localhost:3000. For a deployed site, copy its HTTPS address from your hosting project's domain settings.
2. Choose the exact hostname you will use, including www if applicable. Set only the URL variables shown for your project. Several names may currently require the same origin; do not delete an existing variable just because its value is repeated.
3. After adding a custom domain, update the application URLs, enabled OAuth callbacks, Maps restrictions, and payment endpoints to match it. Save the variables and redeploy.
4. Keep Preview URLs separate from Production. Never put API keys, passwords, or database credentials into a public URL variable.

Screenshots restored from the original guide. Provider interfaces may change; use the written instructions and your selected project's variable names if an older screenshot differs. Never share real credentials in screenshots.

1. Set ADMIN_EMAIL to the email you control and will use for your administrator account. For E-commerce, E-commerce Lite and Taxi, register or sign in with that exact address to receive administrator access; the setting identifies the admin but does not itself create a user or password.
2. For a password-based admin such as Business Landing, generate a strong unique ADMIN_PASSWORD using a password manager or the local Env Builder. Store it securely, then add it to your hosting environment. Do not add this variable to templates that do not consume it.
3. After deployment, sign in and check admin access. In a separate private browser session, confirm that an ordinary visitor cannot open protected admin features.

Screenshots restored from the original guide. Provider interfaces may change; use the written instructions and your selected project's variable names if an older screenshot differs. Never share real credentials in screenshots.

1. Create an account at resend.com.
2. Open API Keys → Create API Key (or Add API Key). Create a sending key with the minimum required scope, copy it immediately, and save it as RESEND_API_KEY.
3. To send from your own address, open Domains → Add Domain and enter your sending domain.
4. Resend shows the DNS records required for verification. Open the DNS dashboard at your domain registrar, add the records exactly as shown, then return to Resend and click Verify. Wait until the domain is verified.
5. Set EMAIL_FROM to an address on that verified domain, for example Website <no-reply@yourdomain.com>. Copy the value without outer quotes into your hosting environment.
6. Redeploy, submit a test booking or order, and check the Resend delivery log and recipient inbox. The default testing sender is restricted; it is not a replacement for a verified customer-facing sender.
7. Resend is optional for the released templates that support it. Without it, the documented fallback does not prove real email delivery. Custom sites that rely on email for sign-in may require it.

Screenshots restored from the original guide. Provider interfaces may change; use the written instructions and your selected project's variable names if an older screenshot differs. Never share real credentials in screenshots.

1. Sign up at Stripe Dashboard. Start in a sandbox or test mode; use live mode only after you have verified the whole payment flow.
2. Business setup: to activate live payments, provide your business name, country, website, services, and the identity/bank details Stripe requests. For a website taking payment for its own goods or services, choose the option for accepting payments for your own business, not a platform or marketplace distributing payments to other sellers. A custom Connect integration must follow its own onboarding flow.
3. Open Developers → API keys (the dashboard may show this under Workbench). Reveal the test secret key and save it as STRIPE_SECRET_KEY. Copy a publishable key only if your project's client-side Stripe integration requires one; the four-template catalog is not a universal contract for custom sites.
4. For E-commerce or Taxi card payments, set a unique STRIPE_DEPLOYMENT_ID for this site and environment. Do not share it between Preview and Production. Configure the separate CRON_SECRET for the reconciliation job.
5. Deploy your application with the required configuration. For the signed webhook, open Developers / Workbench → Webhooks → Add destination, select Your account, and follow the API-version requirements of your integration.
6. Events to send: select every event handled by your selected template, not just the checkout success event.

   For a custom project, use its webhook handler and delivery instructions as the authority. The following lists are the released template examples, not a required combined subscription.

   E-commerce: subscribe to all these events

   • checkout.session.completed
   • payment_intent.succeeded
   • payment_intent.payment_failed
   • checkout.session.expired
   • refund.created
   • refund.updated

   Taxi: subscribe to all these events

   • checkout.session.completed
   • checkout.session.async_payment_succeeded
   • checkout.session.expired
   • checkout.session.async_payment_failed
   • payment_intent.succeeded
   • payment_intent.payment_failed
   • charge.refunded
7. Choose Webhook endpoint, give it a recognizable destination name such as "Preview Website", and enter the endpoint URL. E-commerce and Taxi use /api/stripe/webhooks. Custom projects may have a different route: use their documented path instead of blindly copying this template example.
   Your application URL

   The hostname is preserved, including www. Use your deployed HTTPS origin for Stripe Dashboard delivery.

8. Save the destination → open Destination details → reveal the Signing secret. Copy the whsec_… value into STRIPE_WEBHOOK_SECRET for that exact deployment and redeploy. A local Stripe CLI signing secret is different from a Dashboard destination secret.
9. Configure the authenticated reconciliation schedule from your repository's Stripe guide. A browser return page is not proof of payment. Test successful checkout, failure/expiry, duplicate delivery, refunds, and recovery without the customer returning to the site.
10. Use separate test and live keys, destinations, signing secrets, and deployment IDs. Never put the secret key or signing secret in a browser-visible variable. Taxi can omit Stripe entirely for cash-only operation; E-commerce requires it.

Screenshots restored from the original guide. Provider interfaces may change; use the written instructions and your selected project's variable names if an older screenshot differs. Never share real credentials in screenshots.

1. Sign up at cloudinary.com and choose a plan appropriate for your intended use.
2. Open your Dashboard / Product Environment and note the Cloud name. The Settings → API Keys page contains the API credentials.
3. Server-side upload (for example, Business Landing): copy the Cloud name, API key, and API secret into the server-only fields CLOUDINARY_CLOUD_NAME, CLOUDINARY_API_KEY, and CLOUDINARY_API_SECRET. Never prefix the API secret with NEXT_PUBLIC_. Some custom integrations consume CLOUDINARY_URL instead; use it only if your project reads that variable.
4. Browser upload widget (E-commerce / Taxi): copy the Cloud name into NEXT_PUBLIC_CLOUDINARY_CLOUD_NAME. These templates do not need Cloudinary's private API key or secret for their widget.
5. Open Settings → Upload → Upload presets → Add upload preset. Set the signing mode to Unsigned, choose an upload folder, and restrict file formats, size, transformations, and quotas.
6. Save the preset and copy its exact name into NEXT_PUBLIC_CLOUDINARY_UPLOAD_PRESET. An unsigned preset is public: its upload restrictions matter.
7. Save the values, redeploy, and upload a small supported test image. Confirm that the image appears in Cloudinary and on your site. Use only the upload method your project implements; do not configure both methods by default.

Screenshots restored from the original guide. Provider interfaces may change; use the written instructions and your selected project's variable names if an older screenshot differs. Never share real credentials in screenshots.

1. Go to upstash.com and sign in with Google or GitHub.
2. Click Create Database, enter a name for this environment, and select an appropriate region near your server deployment.
3. Open the new database and find the REST API section on its details page.
4. Copy the HTTPS REST URL into UPSTASH_REDIS_REST_URL and the REST token into UPSTASH_REDIS_REST_TOKEN. Use REST credentials, not a Redis TCP connection URL or a read-only token.
5. Add both server-only values in your hosting environment and redeploy. Use a separate database or an appropriately isolated setup for Preview.
6. Test a protected endpoint with a small, controlled number of requests and verify the configured rate limit. If your project relies on external WAF protection instead, configure and test that rule: merely having a Cloudflare or Vercel account does not protect a specific endpoint automatically.

Screenshots restored from the original guide. Provider interfaces may change; use the written instructions and your selected project's variable names if an older screenshot differs. Never share real credentials in screenshots.

1. Go to Google Cloud Console → project selector → New Project. Name it after your site and connect a billing account for Maps usage.
2. Open APIs & Services → Library. Enable Maps JavaScript API and the Places API variant your browser integration uses. Enable Routes API for Taxi's server-side route calculation. Enable Directions or Geocoding only if your custom integration actually uses them.
3. Open APIs & Services → Credentials → Create Credentials → API key. Create a browser key and copy it into NEXT_PUBLIC_GOOGLE_MAPS_API_KEY.
4. Open that key's settings. Under Application restrictions, choose Websites / HTTP referrers. Add your exact allowed sites, such as https://yourdomain.com/* and, for a development key, http://localhost:3000/*. Under API restrictions, allow only the browser APIs your app uses.
5. Create a second key for the server and save it as GOOGLE_MAPS_SERVER_API_KEY. Restrict its APIs to Routes API for Taxi. Do not apply browser-referrer restrictions to this server key. Apply IP restrictions only when your server has known stable egress IPs.
6. Save both values, redeploy, and test address search, route calculation, distance, and fare calculation. Monitor usage and configure billing alerts. Never reuse one unrestricted key across browser and server.

1. Configure only the analytics, presentation, support-contact, or security overrides listed for your project. Use the provider-issued identifier for analytics, not an API secret.
2. Public presentation settings are visible to visitors. Keep signing keys and scheduler secrets server-only and generate separate values locally.
3. Do not put a GitHub personal access token or other provider secret in public environment variables. Follow your repository's instructions for additional CMS integrations.