Security & Trust
Astralog is built to help engineering teams collect, search, analyze and understand events generated across modern distributed systems. Our objective is simple: Provide a powerful observability platform while minimizing risk, maintaining customer trust and protecting operational data.
Contents
- Product Requirement
- Security Principles
- Data Ownership
- Data Processing
- Encryption
- Authentication
- Authorization
- API Security
- Infrastructure Security
- Network Security
- Production Access
- Data Retention
- Bring Your Own Infra
- Sensitive Data
- Security Monitoring
- Incident Response
- Vulnerability Management
- Responsible Disclosure
- Compliance Roadmap
- Availability & Reliability
- Security Contact
Security is a Product Requirement
Astralog is built to help engineering teams collect, search, analyze and understand events generated across modern distributed systems.
We understand that observability data is often among the most operationally sensitive information inside an organization. Events may contain infrastructure metadata, deployment information, application behavior, request traces, operational diagnostics and security-relevant events.
For this reason, security is not treated as an add-on feature. It is considered a foundational part of the platform's architecture, operational procedures and product roadmap.
Our objective is simple:
Provide a powerful observability platform while minimizing risk, maintaining customer trust and protecting operational data.
Security Principles
Astralog is guided by a small set of security principles that influence every architectural decision.
Least Privilege
Access should only be granted when necessary and only to the systems required to perform a specific task.
Data Minimization
Customers should only send the data required for observability and troubleshooting purposes.
Defense in Depth
Security controls should exist at multiple layers, including infrastructure, storage, authentication, networking and application design.
Transparency
Customers deserve clear information about how their data is handled, stored and protected.
Customer Ownership
Your data belongs to you.
Astralog exists to help you understand your systems—not to monetize, resell or repurpose your operational data.
Data Ownership
All events, events and metadata transmitted to Astralog remain the property of the customer.
Astralog does not claim ownership over:
- Event events
- Structured metadata
- Search indexes
- Source configurations
- Event payloads
- Customer-generated content
Customers retain full ownership of all information submitted to the platform.
Astralog does not sell customer data, advertising data or operational telemetry to third parties.
Data Processing
Astralog processes customer data exclusively for the purpose of providing observability services.
This includes:
- Event ingestion
- Indexing
- Search
- Filtering
- Storage
- Alerting
- Analytics related to platform operation
Customer data is never used to train machine learning models, large language models or artificial intelligence systems.
Customer events are not used for advertising purposes.
Encryption
Encryption in Transit
All communication with Astralog is protected using modern TLS encryption.
Protected communication paths include:
- SDK to ingestion endpoints
- Dashboard traffic
- API requests
- Internal service communication
- Administrative access
Astralog requires HTTPS for all public endpoints.
Supported protections include:
- TLS 1.2+
- TLS 1.3 where available
- Secure cipher suites
- Certificate validation
Encryption at Rest
Stored data benefits from encryption mechanisms provided by our infrastructure providers and storage systems.
This includes:
- Database storage
- Object storage
- Backups
- Search indexes
Data is protected against unauthorized access through layered security controls and storage-level protections.
Authentication
Astralog uses modern authentication systems designed to reduce account compromise risk.
Supported authentication methods may include:
- Email authentication
- Magic links
- GitHub authentication
- Google authentication
- Multi-factor authentication
- Enterprise SSO
Authentication systems are designed to avoid password handling complexity whenever possible.
Authorization
Access to customer resources is restricted through account-level permissions.
Customers can only access resources belonging to their own account or organization.
Future enterprise controls include:
- Role-Based Access Control (RBAC)
- Organization-level permissions
- Team management
- Administrative roles
- Read-only access roles
API Security
Every source connected to Astralog is authenticated using dedicated API credentials.
Each source receives its own unique identity and credentials.
Security controls include:
- Per-source API keys
- Key rotation
- Key revocation
- Source isolation
- Secure key generation
Compromised credentials can be revoked immediately without affecting unrelated services.
Infrastructure Security
Astralog is deployed using modern cloud infrastructure providers and industry-standard operational practices.
Core infrastructure may include:
- Cloudflare
- Object Storage
- ClickHouse
- Managed databases
- Containerized workloads
- Isolated environments
Infrastructure components are continuously monitored for:
- Availability
- Performance
- Operational health
- Service degradation
- Unexpected failures
Network Security
Astralog uses multiple layers of network protections designed to reduce exposure and attack surface.
These protections may include:
- HTTPS enforcement
- Firewall controls
- Traffic filtering
- DDoS protection
- Rate limiting
- Network segmentation
Public-facing systems are designed to expose only the minimum required functionality.
Production Access
Access to production environments is tightly controlled.
Internal access follows the principle of least privilege.
Access controls may include:
- Restricted administrative access
- Multi-factor authentication
- Activity logging
- Audit trails
- Temporary access grants
- Access reviews
Only authorized personnel may access production systems when operationally necessary.
Data Retention
Customers control how long events remain available based on their selected plan.
Retention periods may vary depending on:
- Subscription tier
- Storage configuration
- Enterprise agreements
When retention periods expire, data is automatically removed according to platform policies.
Enterprise customers may configure custom retention requirements.
Bring Your Own Infrastructure
Enterprise customers may choose to maintain additional control over storage and data location.
Bring Your Own Bucket (BYOB)
Astralog can store events directly inside customer-controlled storage environments.
Supported architectures may include:
- Amazon S3
- Cloudflare R2
- Google Cloud Storage
- S3-compatible storage systems
This allows organizations to retain full ownership over stored event data.
Bring Your Own ClickHouse
Organizations already operating ClickHouse infrastructure may integrate Astralog with customer-managed deployments.
Benefits include:
- Infrastructure ownership
- Custom compliance requirements
- Internal governance controls
- Data residency requirements
Sensitive Data Handling
Events frequently contain operationally sensitive information.
Customers should treat observability data as confidential.
We strongly recommend never logging:
- Passwords
- Authentication tokens
- Session secrets
- API credentials
- Encryption keys
- Payment card information
- Personal health information
- Highly sensitive personal information
Engineering teams should implement appropriate filtering and redaction before sending data to any observability platform.
Security Monitoring
Astralog continuously monitors platform health and operational status.
Monitoring may include:
- Service availability
- Infrastructure metrics
- Ingestion health
- Storage health
- Authentication systems
- Operational anomalies
Monitoring exists to support platform reliability and incident detection.
Incident Response
Security incidents are handled according to established internal procedures.
When an incident occurs:
- The issue is identified and investigated.
- Potential impact is assessed.
- Containment measures are applied.
- Recovery actions are executed.
- Corrective actions are implemented.
When required, affected customers will be notified in accordance with applicable obligations and internal policies.
Vulnerability Management
Security vulnerabilities are taken seriously.
Astralog regularly reviews:
- Dependencies
- Infrastructure configurations
- Security updates
- Platform components
Critical vulnerabilities are prioritized for immediate remediation.
Responsible Disclosure
We welcome responsible security research.
If you believe you have discovered a security issue affecting Astralog, please contact:
Please include:
- Description of the issue
- Steps to reproduce
- Potential impact
- Supporting evidence
We appreciate responsible disclosure and will investigate all legitimate reports.
Compliance Roadmap
Astralog is continuously evolving its security and compliance posture.
Planned initiatives may include:
- Role-Based Access Control (RBAC)
- Audit Events
- Single Sign-On (SSO)
- Enterprise Access Controls
- Private Deployments
- Customer-managed storage
- Compliance programs
- Security reviews
- Infrastructure hardening
Features and timelines may change as the platform evolves.
Availability & Reliability
Observability platforms are critical operational infrastructure.
Astralog is designed with reliability as a core objective.
Platform goals include:
- Reliable ingestion
- Durable storage
- Fast search performance
- Operational resilience
- Infrastructure redundancy where appropriate
Service architecture continues to evolve as usage grows.
Security Contact
For security questions, vulnerability disclosures or security-related concerns:
For general support:
For enterprise security reviews:
Our Commitment
Astralog is built for modern distributed systems, AI applications, edge workloads and cloud-native architectures.
We understand that customers trust us with operationally important data.
That trust is earned through transparency, responsible engineering practices and continuous improvement.
Security is not a checkbox.
It is an ongoing commitment.