Skip to content

DNS and Subdomain Map

This document provides a conceptual map of subdomains to purposes and owning products, plus rules for new subdomains. It is written for DevOps teams, architects, and anyone managing ConnectSoft's infrastructure.

This is a logical map, not a DNS provider-specific guide. The main goals are consistent naming, easy-to-understand mapping between URL and product, and clear governance for new subdomains.

Note

Conceptual Map: This document provides a conceptual mapping of subdomains to purposes. Actual DNS configuration is managed separately, but this map serves as the source of truth for subdomain strategy and naming conventions.

Subdomain Overview

Goals

  • Consistent Naming - Clear, predictable subdomain patterns
  • Easy Mapping - Easy to understand which subdomain maps to which product
  • Scalable - Patterns that work as we add more products
  • Governed - Clear process for adding new subdomains

Scope

This map covers: - Public-facing subdomains - Product-specific subdomains - Environment-specific subdomains - Tenant-specific subdomains (optional patterns)

See: Domains Overview for domain strategy.

Core Subdomain Map

Subdomain Purpose Owning Product/Area
www.connectsoft.ai Main AI Factory / platform site Marketing & Platform
console.connectsoft.ai Factory UI (projects, runs, agents) Factory
api.connectsoft.ai Factory API endpoint Factory
agents.connectsoft.ai Agent orchestration API (optional) Factory
www.connectsoft.io SaaS marketplace hub Product / GTM
app.connectsoft.io Unified portal for all products Product / GTM
identity.connectsoft.io Identity Platform SaaS UI Identity Platform
audit.connectsoft.io Audit Platform SaaS UI Audit Platform
config.connectsoft.io Config Platform SaaS UI Config Platform
bot.connectsoft.io Bot Platform SaaS UI Bot Platform
employment.connectsoft.io Employment Services SaaS Employment Services Domain
www.connectsoft.dev Developer portal entry Developer Experience
docs.connectsoft.dev Full MkDocs site Developer Experience
api.connectsoft.dev Shared API entry (if used) Dev Portal / API Gateway
www.connectsoft.co.il Local Israeli site Local / Regional

See: AI Domain Strategy for .ai subdomains.

See: IO Domain Strategy for .io subdomains.

See: Dev Domain Strategy for .dev subdomains.

Product and Environment Patterns

Product Subdomain Pattern

Pattern: <product>.connectsoft.io

Examples: - identity.connectsoft.io - Identity Platform - audit.connectsoft.io - Audit Platform - config.connectsoft.io - Config Platform - bot.connectsoft.io - Bot Platform - employment.connectsoft.io - Employment Services SaaS

Environment Subdomain Pattern

Pattern: <product>-<env>.connectsoft.io

Examples: - audit-dev.connectsoft.io - Audit Platform development environment - audit-staging.connectsoft.io - Audit Platform staging environment - audit.connectsoft.io - Audit Platform production environment

Alternative Pattern (if needed): - audit-prod.connectsoft.io - Explicit production environment

Important

Environment Naming: 1. Use -dev suffix for development environments 2. Use -staging suffix for staging environments 3. Use no suffix (or -prod) for production environments 4. Keep environment naming consistent across all products

Tenant Subdomain Pattern (Optional)

Pattern: <tenant>.<product>.connectsoft.io

Examples: - sploot.audit.connectsoft.io - Sploot tenant on Audit Platform - megacorp.audit.connectsoft.io - Megacorp tenant on Audit Platform

Note: Tenant subdomains are optional. Primary pattern is tenant-as-path: audit.connectsoft.io/t/{tenant}/...

See: IO Domain Strategy for tenancy patterns.

Governance and Approval Process

Who Can Propose

Can Propose New Subdomains: - Architects (for new products or services) - Product Owners (for new product subdomains) - DevOps/SRE (for infrastructure subdomains) - Marketing (for marketing subdomains)

Who Approves

Approval Authority: - Dmitry / Platform Owner - Final approval for all public subdomains - Architecture Review - Technical review for new product subdomains - Marketing Review - Branding review for marketing subdomains

Process

Steps: 1. Proposer creates proposal with justification 2. Technical review (architecture, naming, routing) 3. Branding review (if marketing-related) 4. Approval from platform owner 5. Update DNS Subdomain Map document 6. Implement DNS configuration 7. Update routing and infrastructure

See: Domains Overview for domain strategy.

Naming Rules and Conventions

Subdomain Naming Rules

  • Use Lowercase - All subdomains must be lowercase
  • Hyphen-Separated - Use hyphens to separate words (e.g., audit-platform.connectsoft.io)
  • Clear Product Names - Use clear, descriptive product names
  • Avoid Ambiguity - Avoid ambiguous or confusing names
  • Consistent Patterns - Follow established patterns (product, environment, tenant)

Product Name Consistency

Product Names Must Match: - Product portfolio documentation - Internal product names - Marketing materials - API endpoints (where applicable)

Examples: - identity (not id, iam, auth) - audit (not audit-trail, auditing) - config (not configuration, settings)

Tip

Naming Consistency: Ensure subdomain names are consistent with product names in portfolio docs. This makes it easy for users to find the right subdomain for a product they're looking for.

Future-Proofing Guidelines

Marketplace Modules

Future Pattern: <module>.connectsoft.io

Examples (Speculative): - payment-module.connectsoft.io - Payment module marketplace entry - analytics-module.connectsoft.io - Analytics module marketplace entry

Note: Marketplace modules may use subdomains or paths. Decision pending marketplace strategy.

See: Marketplace Strategy for marketplace strategy.

Regional Variants

Future Pattern (if needed): <region>.connectsoft.io

Examples (Speculative): - eu.connectsoft.io - European region variant - us.connectsoft.io - US region variant

Note: Regional variants are speculative and not currently planned. If needed, they would follow the same naming conventions.

Backward Compatibility

Decision

Backward Compatibility Rule: Domain and subdomain strategy must be backward-compatible where possible. Avoid frequent changes to subdomain names. If changes are necessary, use redirects to maintain compatibility. This ensures existing links, bookmarks, and integrations continue to work.