📁Projects & Environments

Every product you protect with DevPayr begins as a Project — but how and where that project is used is determined by its Environments.

Understanding how DevPayr handles Projects, Domains, and Environments will help you structure your deployments cleanly, enforce licensing correctly, and avoid unexpected behavior during development, staging, and production.

This page gives you the complete picture of how DevPayr treats environments and how licenses behave differently depending on where your software is running.

🧱 What Is a Project?

A Project represents a single software product you want to protect with DevPayr. This could be:

• A SaaS application

• A client dashboard

• A theme, plugin, or template

• A mobile or desktop application

• An internal enterprise system

• A backend service or API

Each project contains:

• All licenses for that product

• Its domains

• API keys

• Injectables

• Validation rules

• Usage limits

• Metadata

• Payment status (has_paid)

A project does not define environments by itself. Instead, environments are created when you add domains to your project.

🌍 Domains Define Environments

In DevPayr, an environment is tied directly to a domain, not the project.

When you add a domain to a project, you assign it an environment such as:

• development

• staging

• production

This allows you to precisely control:

• Where test licenses can run

• Where production licenses can run

• How validation behaves in different deployment setups

Example Setup:

Domain	Environment
localhost	(auto-relaxed – no need to add)
staging.clientapp.com	staging
clientapp.com	production

Once domains are added, they become the authority for environment validation.

🧪 Local Environments (Automatically Relaxed)

DevPayr understands that development should not feel like a security checkpoint.

For this reason, DevPayr automatically relaxes restrictions for the following local/test-style domains:

• localhost

• 127.0.0.1

• anything ending in .test (e.g., myapp.test)

When running on these domains:

• Test licenses work fully

• Domain restrictions are relaxed

• Environment mismatches are ignored

• Validation remains safe but flexible

This ensures smooth development without needing to manually configure anything.

🧪 Test Licenses vs Production Licenses

DevPayr enforces different rules depending on the license type and the domain environment.

✔ Test Licenses

Test licenses are created specifically for development and staging scenarios.

They can run on:

• Local development domains (localhost, 127.0.0.1, .test)

• Project domains marked as development

• Project domains marked as staging

They cannot run on:

• Production domains

This ensures test licenses cannot accidentally power live deployments.

✔ Production Licenses

Production licenses are meant for real customer environments.

They can run only on:

• Domains marked as production

They cannot run on:

• Development domains

• Staging domains

• Local domains (unless intentionally relaxed by your SDK behavior)

This prevents production licenses from being misused during development, or used in multiple environments improperly.

🔍 Domain Authorization

For a deployment to validate correctly:

1. The request must indicate which domain it’s running on

2. That domain must exist under the project (or under the license)

3. The environment assigned to that domain dictates which licenses are allowed

If a domain is not registered under the project, DevPayr rejects the request. This protects you from unauthorized deployments or cloned environments.

🔄 How Environments Influence Validation

Here’s the behavior breakdown:

🟩 Local (Development)

• Relaxed restrictions

• Perfect for coding, testing, experimenting

• Test licenses behave fully

• Production licenses may still be blocked depending on configuration

🟧 Staging / Testing

• Test licenses allowed

• Production licenses blocked

• Domain authorization applies

• Useful for demos, QA, preview servers

🟥 Production

• Strict enforcement

• Only production licenses allowed

• All limitations fully active:

  • domain restrictions

  • usage limits

  • expiration

  • IP/country restrictions

  • payment enforcement

• Injectables load only if paid

This is where DevPayr protects you the most.

🧭 Example Workflow

A typical environment workflow looks like this:

1. Develop locally

   • Use a test license

   • Domain rules relaxed

2. Deploy to staging

   • Use a test license or staging license

   • Preview features

   • QA and demos happen here

3. Deploy to production

   • Use a production license

   • Domain restrictions enforced

   • Payment status enforced

   • Usage and environment rules active

This mirrors real-world software lifecycles.

🧩 Why DevPayr Uses Domain-Based Environments

This approach gives you:

✔ Full control

You decide exactly where your software can run — and how.

✔ Clear separation

Staging cannot accidentally use production licenses. Production cannot accidentally use test licenses.

✔ Predictable behavior

Environment rules are based on explicit domain settings, not guessing.

✔ Security

Unauthorized deployments fail immediately.

✔ Flexibility

Multi-domain products, multi-brand instances, and multi-environment architectures work seamlessly.

🎉 Summary

• Projects hold your product’s configuration

• Domains hold your environments

• Environments determine how licenses behave

• Test licenses are allowed on dev/staging domains

• Production licenses are allowed only on production domains

• Local/test-like domains (localhost, .test) are automatically relaxed

• Domain registration is required for production enforcement

• DevPayr ensures deployments happen in the right environment with the right license

With this foundation in mind, everything else in DevPayr — licensing, injectables, validation, automation — becomes far easier to understand.