# Service Deployment Defaults

## Purpose

Default assumptions for homelab service requests so agents do not repeatedly ask the user the same low-value questions.

These are defaults, not immutable rules. Verify when risk is high or when the user's request implies a different requirement.

## Meaning of "Self-hosted"

When the user asks for a self-hosted service, assume a managed homelab deployment, usually on Proxmox, not an ad hoc app running from the current PC/folder.

Default expectation:

- Proxmox LXC unless a VM is required
- LAN + Tailscale access
- service runbook
- backup/restore plan
- update plan
- DNS/TLS plan
- dashboard/monitoring registration when implemented

Local-only prototypes are allowed, but should be explicitly labeled as prototypes and should not become the assumed production architecture.

## Access Boundary

Default for new homelab services:

- **LAN + Tailscale only**
- No public internet exposure unless the user explicitly asks for it
- Avoid public port forwarding by default
- Prefer private/admin access paths first, then deliberately design external access if needed

## DNS Naming

Primary domain:

- `dropcutstud.io`

Default hostname convention:

- simple, single-word, memorable hostnames based on the service name
- example: a ticketing service would normally use `tickets.dropcutstud.io`

Current DNS situation:

- `*.dropcutstud.io` currently points to the external IP
- OPNsense/Unbound local overrides/exceptions are used for internal resolution
- This setup is known to be imperfect and should be improved

## TLS / Reverse Proxy

No final standard TLS solution is in place yet.

Preferred direction:

- deploy an Nginx reverse proxy service on the server/homelab
- centralize TLS handling there where practical
- decide certificate flow during the reverse-proxy/TLS project

## Proxmox Guest Type

Default guest type:

- **LXC preferred** for new services
- Use a full VM only when isolation, kernel/system requirements, appliance constraints, or compatibility make LXC unsuitable

## Backups

Backups are required for real/important services, but the standard backup system is still being implemented.

Agents should not ask generic backup questions every time. Instead:

1. Check existing backup tickets/runbooks/status.
2. Apply the service template/default backup class if available.
3. Ask the user only for service-specific retention or criticality decisions that are not already documented.

## Authentication

Authentication should be decided after product selection and threat model.

Current preference/expectation:

- do not ask detailed auth-stack questions too early
- local users may be acceptable for MVPs
- future centralized auth may involve Vaultwarden-adjacent secret handling, SSO, Authelia, LDAP, or Nextcloud integration, but this is not decided

## Ticket/Task System Assumption

If the user asks to create a ticketing/task system for Nimrod and the user, assume the goal is to move toward a canonical coordination system, not create redundant parallel systems.

During transition, markdown tickets in this repo remain the current source of truth until a deliberate migration/integration plan is approved.

Agents should ask about coexistence/migration only when it materially affects implementation timing or data migration.

## Asking Questions

Avoid asking questions whose answers can be inferred from these defaults.

Prefer asking judgment questions such as:

- Is this service important/critical or experimental?
- Are there must-have features that would rule out common tools?
- Is there an explicit reason this service needs public internet exposure?
- Is there a reason LXC is unsuitable for this service?