> ## Documentation Index
> Fetch the complete documentation index at: https://docs.knoxcall.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Client Types Explained
> Deep dive into Server and User client types. Learn when to use each type and best practices.
# Client Types Explained
KnoxCall supports two types of clients, each optimized for different use cases. Both types support single IPs and CIDR ranges. This guide helps you choose the right type.
***
## The Two Types
| Type | Best For | IP Stability | Example |
| ---------- | -------------------------------------------------- | -------------------- | ------------------------------------------------ |
| **Server** | Production servers, office networks, cloud subnets | Static (unchanging) | AWS EC2 with Elastic IP, office `192.168.1.0/24` |
| **User** | Developer machines, QA testers | Dynamic (may change) | Laptop on home Wi-Fi |
***
## Server Type
### Overview
**Server** clients represent production infrastructure with **static IP addresses** that never (or rarely) change.
### Characteristics
✅ **Static IP address** - IP doesn't change
✅ **Production-ready** - Designed for reliability
✅ **Single IP** - One specific address
✅ **High trust** - Critical infrastructure
### When to Use
Use **Server** type when:
* Production API servers
* Staging servers
* Database servers
* Backend services with static IPs
* Cloud instances with Elastic IPs
* VPS with dedicated IPs
* Partner webhook servers
### Examples
#### AWS EC2 with Elastic IP
```text theme={"dark"}
Name: prod-api-server-1
Type: Server
IP: 52.123.45.67
Description: Main production API server in AWS us-east-1
```
**Why Server type:**
* Elastic IP is static (never changes unless you release it)
* Production traffic
* Critical infrastructure
#### DigitalOcean Droplet
```text theme={"dark"}
Name: staging-backend
Type: Server
IP: 159.65.123.45
Description: Staging environment backend on DigitalOcean
```
**Why Server type:**
* Droplet has static IP
* Staging environment (important but not production)
#### Partner Integration
```text theme={"dark"}
Name: partner-acme-webhook
Type: Server
IP: 100.25.30.45
Description: ACME Corp webhook callback server
```
**Why Server type:**
* External partner's server
* Fixed IP address
* Business-critical integration
### Best Practices
✅ **Do:**
* Always use for production
* Document server purpose in description
* Use meaningful names (`prod-api-1` not `server1`)
* Track in inventory (spreadsheet/wiki)
* Regular security audits
❌ **Don't:**
* Use for developer laptops (use User type)
* Use for dynamic IPs (IP will change, causing issues)
* Use for IP ranges without also locking down the server identity
***
## User Type
### Overview
**User** clients represent individual people or devices with **potentially dynamic IP addresses**.
### Characteristics
✅ **Dynamic IP** - May change occasionally
✅ **Individual person/device** - Not infrastructure
✅ **Development-focused** - Testing, debugging
✅ **Lower trust** - Temporary access
### When to Use
Use **User** type when:
* Developer laptops
* Home office machines
* QA team computers
* Temporary contractor access
* Mobile devices (rare)
* Any IP that might change
### Examples
#### Developer Laptop
```text theme={"dark"}
Name: john-dev-macbook
Type: User
IP: 203.45.67.89
Description: John's MacBook Pro for local development
```
**Why User type:**
* Home Wi-Fi IP changes occasionally
* Individual developer
* Development/testing only
#### QA Team Member
```text theme={"dark"}
Name: qa-alice-laptop
Type: User
IP: 180.123.45.67
Description: Alice (QA) - testing environment access
```
**Why User type:**
* Office IP might change
* Individual tester
* Non-production use
#### Remote Contractor
```text theme={"dark"}
Name: contractor-bob-temp
Type: User
IP: 192.5.8.100
Description: Bob (contractor) - temporary access for Q1 2025
```
**Why User type:**
* Temporary access
* Individual person
* Dynamic IP likely
### Dynamic IP Challenges
**Problem:** Home/office internet usually has dynamic IPs that change.
**When IPs change:**
* Router restarts
* ISP lease expires (every 24-72 hours typically)
* VPN connects/disconnects
* Moving locations
**Solutions:**
**Option 1: Update IP when it changes**
```bash theme={"dark"}
# Check current IP
curl https://api.ipify.org
# Update client in KnoxCall UI
# Resources → Clients → Edit → Update IP
```
**Option 2: Use API key authentication**
* Create API key with "Allow any IP"
* Use key in requests instead
* No IP whitelisting needed
**Option 3: Use VPN with static IP**
* Connect to VPN with static egress IP
* Whitelist VPN IP
* Always connect through VPN
### Best Practices
✅ **Do:**
* Include person's name in client name
* Update description with contact info
* Remove when person leaves company
* Use "Allow any IP" API keys for dev (easier)
* Assign only to dev/staging environments
❌ **Don't:**
* Use for production servers
* Give production access to User clients
* Forget to remove when contractor leaves
* Use generic names like `user1`
***
## Using CIDR Ranges
Both Server and User types support **CIDR notation** for authorizing IP ranges. This is useful for office networks, VPNs, and cloud subnets.
### Examples with CIDR
#### Office Network
```text theme={"dark"}
Name: office-wifi-main
Type: Server
IP: 192.168.1.0/24
Description: Main office Wi-Fi - all floors, ~200 employees
```
Covers 256 addresses: `192.168.1.0` to `192.168.1.255`
#### Corporate VPN
```text theme={"dark"}
Name: company-vpn
Type: Server
IP: 10.8.0.0/16
Description: Corporate VPN - all remote employees
```
Covers 65,536 addresses: `10.8.0.0` to `10.8.255.255`
#### Cloud Provider Subnet
```text theme={"dark"}
Name: aws-us-east-subnet
Type: Server
IP: 172.31.0.0/20
Description: AWS VPC subnet for microservices
```
Covers 4,096 addresses: `172.31.0.0` to `172.31.15.255`
### Common CIDR Ranges
* `/32` - 1 IP (just enter the IP without `/32`)
* `/24` - 256 IPs (e.g., `192.168.1.0/24`)
* `/16` - 65,536 IPs (e.g., `10.0.0.0/16`)
* `/8` - 16,777,216 IPs (very large, rare)
See [CIDR Notation Guide](/essentials/clients/cidr-notation) for details.
### CIDR Best Practices
✅ **Do:**
* Use smallest range that covers your needs
* Document what network the range represents
* Audit periodically (remove if unused)
❌ **Don't:**
* Use `0.0.0.0/0` (allows entire internet!)
* Use overly broad ranges unnecessarily
***
## Comparison Table
| Feature | Server | User |
| --------------- | ----------------------------------- | ----------------------------- |
| **IP Format** | Single IP or CIDR range | Single IP or CIDR range |
| **Example IP** | `52.123.45.67` or `192.168.1.0/24` | `203.45.67.89` |
| **Stability** | Permanent | May change |
| **Use Case** | Production servers, office networks | Developer laptops, QA testers |
| **Trust Level** | High | Medium |
| **Environment** | Production, Staging | Dev/Staging |
| **Maintenance** | Low | Medium (IP updates) |
***
## Choosing the Right Type
### Decision Tree
```text theme={"dark"}
Is this infrastructure (servers, networks, VPNs)?
├─ YES → Use Server type
└─ NO → Is this a person (developer, tester)?
└─ YES → Use User type
```
### Examples
**Scenario: AWS EC2 instance**
* Infrastructure? ✅ Yes (static Elastic IP)
* **→ Server type**
**Scenario: Developer's laptop**
* Infrastructure? ❌ No (person's device)
* **→ User type**
**Scenario: Office with 50 employees**
* Infrastructure? ✅ Yes (network)
* **→ Server type** with CIDR range (e.g., `192.168.1.0/24`)
**Scenario: VPN with 100 users**
* Infrastructure? ✅ Yes (VPN network)
* **→ Server type** with CIDR range (e.g., `10.8.0.0/16`)
***
## Security Considerations
### Trust Levels
**Server (Highest Trust):**
* ✅ Production traffic allowed
* ✅ Access to sensitive data
* ✅ Critical operations
* ⚠️ CIDR ranges increase exposure — use the smallest range needed
**User (Medium Trust):**
* ⚠️ Development/staging only
* ⚠️ Limited permissions
* ⚠️ Regular audits
### Recommendations by Environment
**Production:**
* ✅ Server type only
* ❌ No User types
* ⚠️ CIDR ranges only for trusted corporate networks
**Staging:**
* ✅ Server type for staging servers
* ✅ User type for QA team
**Development:**
* ✅ Both types acceptable
* ✅ User type most common
* ✅ API keys easier than IP whitelisting
***
## Migration Between Types
### User → Server (When Getting Static IP)
**Before:**
```text theme={"dark"}
Name: dev-server
Type: User
IP: 203.45.67.89 (dynamic)
```
**After getting Elastic IP:**
```text theme={"dark"}
Name: prod-api-server
Type: Server
IP: 52.123.45.67 (Elastic IP - static)
```
**Steps:**
1. Provision Elastic IP from cloud provider
2. Assign to instance
3. Edit client in KnoxCall
4. Change type to Server
5. Update IP to Elastic IP
6. Update description
7. Save
### Network → Multiple Servers
**Before (inefficient):**
```text theme={"dark"}
Name: cloud-subnet
Type: Server
IP: 172.31.0.0/20
Description: All instances (10 production, 50 dev)
```
**After (more secure):**
```text theme={"dark"}
Production servers (Server type):
- prod-api-1: 172.31.1.10
- prod-api-2: 172.31.1.11
- prod-db-1: 172.31.1.20
Development network (Server type with CIDR):
- dev-subnet: 172.31.8.0/22
```
**Benefit:** Production servers explicitly listed, dev instances in subnet.
***
## Real-World Patterns
### Pattern 1: Startup (Small Team)
```text theme={"dark"}
Production:
- Server: prod-api (52.123.45.67)
- Server: prod-db (52.123.45.68)
Development:
- User: john-laptop (dynamic)
- User: jane-laptop (dynamic)
- User: bob-laptop (dynamic)
```
**Why:** Simple setup, few people, API keys easier than IP management for devs.
### Pattern 2: Enterprise (Large Team)
```text theme={"dark"}
Production:
- Server: prod-api-1 through prod-api-10 (specific IPs)
- Server: prod-worker-1 through prod-worker-5
Staging:
- Server: staging-subnet (10.1.0.0/24)
- Server: office-network (192.168.0.0/16)
Development:
- Server: dev-vpn (10.8.0.0/16)
```
**Why:** Granular production control, convenient staging/dev access.
### Pattern 3: Agency/Consultancy
```text theme={"dark"}
Clients:
- Server: client-acme-network (203.14.0.0/24)
- Server: client-widgets-vpn (10.9.0.0/16)
- Server: client-globex-server (100.25.30.45)
Internal:
- Server: office-wifi (192.168.1.0/24)
- User: contractor-alice (temporary)
- User: contractor-bob (temporary)
```
**Why:** Each client gets appropriate access, contractors temporary User type.
***
## Quick Reference
| Situation | Type | Example |
| --------------------------------- | ------ | ---------------- |
| Production server with Elastic IP | Server | `52.123.45.67` |
| Developer's laptop at home | User | `203.45.67.89` |
| Office Wi-Fi network | Server | `192.168.1.0/24` |
| Staging server on cloud | Server | `54.200.11.22` |
| QA team member | User | `180.123.45.67` |
| Corporate VPN | Server | `10.8.0.0/16` |
| Partner's webhook server | Server | `100.25.30.45` |
| Temporary contractor | User | `192.5.8.100` |
***
## Next Steps
Client basics and concepts
Create, edit, assign clients
Understanding IP ranges (coming soon)
Troubleshoot IP problems
***
**Pro Tip:** For production, always use **Server** type with static IPs. For development, use **User** type or API keys with "Allow any IP" to avoid constant IP updates.