Source Control & Export Policy
Last updated: 24 September 2026
At ProjectHelm, we believe you should own what you build. Every line of C# and ASP.NET Core code generated by ProjectHelm belongs completely to you under an open, permissive model with zero proprietary lock-in. This policy explains our commitments regarding source code ownership, multi-database generation, download and Git sanitization, and container storage boundaries. It forms part of our Terms of Service.
1. Full Source Code Ownership & Zero Lock-in
You own 100% of the intellectual property in the source code, data models, business rules, Razor views, and assets generated for your application. You are free to export, download, modify, license, or self-host your application on any infrastructure (AWS, Azure, DigitalOcean, bare-metal servers, or your local machine) without recurring platform royalties or licensing restrictions.
The generated codebase is built on clean, modern, idiomatic ASP.NET Core 10.0 and Entity Framework Core, requiring zero proprietary ProjectHelm runtimes or closed libraries.
2. Multi-Database Architecture & Export Formats
While internal managed hosting uses ultra-fast, single-tenant SQLite (data/app.db) with high-efficiency
bind mounts, ProjectHelm supports first-class multi-database export for self-hosting. You can configure your project's target
database engine at any time:
- SQLite — Default for internal container hosting and single-node instances.
- PostgreSQL — Configured with Npgsql Entity Framework Core, including universal UTC timestamp normalization.
- Microsoft SQL Server — Configured with official SqlServer Entity Framework Core provider.
- MySQL / MariaDB — Configured with Pomelo Entity Framework Core.
- Oracle Database — Configured with official Oracle Entity Framework Core provider.
When you download the source package or synchronize with a remote Git repository, ProjectHelm automatically switches package dependencies,
connection strings, and database provider configuration in Program.cs and AppDbContextFactory.cs to match your selected target database.
3. Download & Git Sync Sanitization (Zero-Trust Security)
To ensure complete decoupling and privacy, every source code export (zip download or Git push) passes through our automated Source Package Sanitizer:
- Blanked Application Secrets: All sensitive credentials, tokens, connection strings, and encryption keys in
appsettings.jsonare recursively reset to blank values ("") while preserving file structure and configuration keys. - Container Hook Decoupling: The internal container quota monitoring hook (
ContainerHostingHooks.cs) and its service registrations are completely removed from the exported solution. Self-hosted deployments run as pure, standard ASP.NET Core applications. - Platform Mail Decoupling: Internal platform mail endpoints and fallback secret keys are eliminated and replaced with standard, configurable SMTP connector defaults.
- Platform Incident Reporter Removal: Internal platform telemetry and error hooks (
PlatformIncidentReporter.cs) are completely stripped.
4. In-Container Storage Quotas & Project Isolation
For applications hosted on ProjectHelm's managed container infrastructure:
- Proactive Pre-Write Quota Validation: Applications running inside managed containers enforce an active storage quota hook. Before any uploaded file or media is written to disk, the incoming file size is evaluated against the current disk consumption and project cap. Uploads exceeding the cap are safely rejected to protect container stability and prevent system crashes.
- Granular Project Isolation: Storage quotas are configured per project within the workspace pool. If an individual application (e.g. a media-intensive application) reaches 100% of its storage cap, only that specific project has its file uploads blocked. All other applications and services in your workspace continue running normally.
- Increments & Storage Pricing: Project storage is allocated in 50 MB increments at 2 credits per 50 MB block per day (up to a standard maximum of 500 MB). Because persistent data volumes are preserved even when an app is offline, storage is charged daily until the project is deleted. Workspaces can enable Auto-Upgrade Storage to automatically add 50 MB at 80% quota.
5. Data Persistence & Taking Apps Offline
Uploaded files, database storage, and cryptographic data protection keys reside on persistent host volumes bind-mounted to your container. Taking an application offline stops container compute and frees hosting compute charges (5 credits/day), while persistent volume storage continues at 2 credits / 50 MB / day to safely preserve your database and assets until you choose to publish again or delete the project.