[P0][security] Disable TypeORM schema synchronization outside development

[dzekojohn4]

Evidence: backend/src/app.module.ts:74 passes database.synchronize directly to TypeORM; README documents DATABASE_SYNC=true.

Ensure production and CI environments cannot enable destructive schema synchronization. Add migration-based startup documentation and a regression test for environment-specific behavior.

[blegodwin]

@blegodwin has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi there, I'd like to contribute to this.

I'll treat this as security-sensitive: careful implementation, no logging of sensitive values, and coverage for the edge cases called out.

Happy to get started right away if assigned — looking forward to contributing.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @blegodwin to this issue.

[ibochivincent-lang]

@ibochivincent-lang has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I’d like to work on Issue #255 because allowing TypeORM schema synchronization to be enabled outside development can make application startup perform unintended or destructive database schema changes. For a production application, schema evolution should be controlled through reviewed migrations rather than automatic synchronization.

I will first review backend/src/app.module.ts, the database configuration, environment handling, README instructions, and any existing TypeORM migration setup to understand how database.synchronize is currently determined.

I will then change the configuration so automatic schema synchronization is permitted only in an explicitly supported development environment. Production and CI will force synchronization off regardless of whether an environment variable attempts to enable it.

I will pay particular attention to the existing DATABASE_SYNC=true documentation and replace or revise it so contributors understand that synchronization is a development-only convenience and cannot be used for production schema changes.

I will document a migration-based startup workflow covering how database migrations should be created, reviewed, executed, and applied during deployment. This will make the safe production path explicit rather than simply disabling the dangerous setting.

For regression coverage, I will add tests that exercise the database configuration under development, production, and CI-like environments. The tests will verify that synchronization can be enabled only where intended and is forced off for production and CI even when the corresponding environment variable is set.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @ibochivincent-lang to this issue.

[sanctus-mvp]

@sanctus-mvp has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I will love to work on this issue please. I deliver high impact solutions, ensuring seamless workflow and client satisfaction

ℹ️ Repo Maintainers: To accept this application, review their application or assign @sanctus-mvp to this issue.

[Magrexy]

@Magrexy has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I'm eager to help secure the Stellar backend by ensuring TypeORM schema synchronization can never run outside development. The core deliverable is disabling destructive auto-schema sync in production and CI environments while keeping it available locally. My approach is to gate synchronization behind an explicit environment check, document migration-based startup, and add a regression test for environment-specific behavior.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Magrexy to this issue.

[Kappa16]

@Kappa16 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi MAINTAINER, I'd like to take this on.
I understand what's being asked here and I'm confident I can implement an accurate fix correctly and efficiently. pls i beg of you just help me out

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Kappa16 to this issue.

[Alimzy]

@Alimzy has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi! I'd like to work on this issue.

I'm a software engineer with hands-on experience in testing, debugging, and building reliable features across the stack. I'm confident I can take this on and deliver a solid, well-tested solution that follows the project's existing conventions.

I'll make sure to cover the core functionality as well as relevant edge cases to keep things reliable and regression-resistant.

Let me know if I can get started, and I'll provide updates as I progress.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Alimzy to this issue.

[drips-wave]

Congratulations, @Magrexy! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @Magrexy: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊