Deploying BodegaX to a production environment involves three independent layers: the static Angular frontend (generated as aDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/Edwin950821/BodegaX/llms.txt
Use this file to discover all available pages before exploring further.
dist/ folder by ng build), the Spring Boot backend API (packaged as an executable JAR), and a managed or self-hosted PostgreSQL 14+ database. This page covers all deployment targets documented in the project, with the most detail on the Google Cloud Platform path, which is the primary recommended deployment target identified in the BodegaX technical documentation.
Frontend Deployment
Runningng build (with no extra flags) uses the production configuration defined in angular.json, which enables full optimization, output hashing (outputHashing: all), and enforces bundle size budgets (warning at 500 KB, error at 1 MB for the initial bundle). The resulting static files are placed in dist/bodega-x-angular/.
dist/bodega-x-angular/ directory contains index.html, hashed JavaScript bundles, hashed CSS files, favicon.ico, and everything under src/assets/. These files are completely static and can be served from any web server or CDN.
- Firebase Hosting
- Google Cloud Storage
- AWS S3 + CloudFront
- Nginx / Apache
Firebase Hosting is the simplest deployment option for the Angular frontend and integrates natively with Google Cloud.Firebase Hosting automatically provisions a CDN, global edge caching, and a free SSL certificate. The
The BodegaX repository does not include a
firebase.json. Running firebase init hosting will generate this file for you interactively. Answer the prompts as shown in the comments below.firebase init hosting command creates firebase.json with a rewrites rule that sends all routes to index.html, which is required for Angular’s client-side routing.Backend Deployment
The Spring Boot backend is packaged as an executable JAR containing an embedded Tomcat server. For production, always setspring.jpa.hibernate.ddl-auto=none or validate to prevent accidental schema changes, and supply database credentials via environment variables rather than hardcoding them in application.properties.
- Google Cloud Run
- Google Kubernetes Engine
- AWS ECS Fargate
- Self-Hosted JAR
Cloud Run is the recommended backend deployment target for BodegaX. It is fully managed, scales to zero when idle, and integrates with Cloud SQL via the Cloud SQL Auth Proxy.
The BodegaX repository does not include a
Dockerfile. You must create one in the backend project root before building the container image. The example below is a minimal starting point for a Spring Boot 3.x application on Java 17.Database Deployment
Google Cloud SQL
Managed PostgreSQL on GCP. Supports automated backups, high availability replicas, and point-in-time recovery. Connect the Spring Boot backend via the Cloud SQL Auth Proxy (recommended for Cloud Run) or direct private IP. Select PostgreSQL 14 or later when creating the instance.
AWS RDS for PostgreSQL
Managed PostgreSQL on AWS. Provides automated backups, Multi-AZ failover, and read replicas. Choose
db.t3.micro for low-traffic deployments or db.m5.large for production workloads. Use the RDS endpoint URL in SPRING_DATASOURCE_URL.Self-Hosted PostgreSQL
Install PostgreSQL 14+ on any VM or bare-metal server. You are responsible for backups, upgrades, and high availability. Use
pg_dump / pg_restore for regular backups. Ensure the database port (5432) is accessible only from the backend server’s IP address.Recommended Deployment: Google Cloud Platform
The following steps cover the complete end-to-end GCP deployment — the path described as recommended in the BodegaX technical documentation.Provision Cloud SQL (PostgreSQL)
Create a Cloud SQL PostgreSQL 14 instance and a dedicated database for BodegaX:Note the connection name for your instance (formatted as
PROJECT:REGION:INSTANCE). You will need it when deploying to Cloud Run.Update the API Base URL in Angular Source
Before building the frontend, replace every hardcoded If you have not yet introduced environment files, perform a find-and-replace across the
http://localhost:8080 reference in the Angular source with your production Cloud Run URL. If you have introduced Angular environment files (strongly recommended), update src/environments/environment.prod.ts:src/ directory:Build the Angular Frontend
Generate the production build of the Angular app:The optimized, hashed output is written to
dist/bodega-x-angular/. Confirm the bundle sizes are within the configured budgets (initial bundle warning at 500 KB, error at 1 MB).Deploy the Frontend to Firebase Hosting
Initialize Firebase Hosting — the BodegaX repository does not include a Firebase Hosting provides an automatic SSL certificate and a global CDN. The deployed URL will be
firebase.json, so firebase init hosting must be run once to create it. Answer the interactive prompts as shown below, then deploy:https://YOUR_PROJECT_ID.web.app.Containerize and Push the Spring Boot Backend
Build the Spring Boot JAR, then build and push the Docker image to Google Artifact Registry:
Deploy the Backend to Cloud Run
Deploy the container to Cloud Run with the Cloud SQL connection and environment variables:Cloud Run will return the public HTTPS URL for your backend. This is the URL you must use in Step 3 as the Angular
apiUrl.Verify the Full Deployment
Open your Firebase Hosting URL in a browser and confirm the login page loads. Attempt to sign in with the admin account you created during local setup. Check the Cloud Run logs for any backend errors:Confirm that API responses arrive in under 2 seconds (per the
RNF10 performance requirement) and that the initial frontend load completes in under 3 seconds (RNF11).Production Configuration Checklist
Security
- Enable HTTPS on both the frontend (automatic with Firebase Hosting / CloudFront) and the backend (Cloud Run provides HTTPS by default)
- Set
SPRING_JPA_HIBERNATE_DDL_AUTO=noneorvalidate— nevercreateorupdatein production - Store all credentials (database password, JWT secret) in environment variables or a secrets manager — never commit them to
application.properties - Ensure CORS is configured on the Spring Boot backend to allow requests only from your production frontend domain
Performance
- API response time: ≤ 2 seconds per request (
RNF10) - Initial Angular frontend load: ≤ 3 seconds on a standard connection (
RNF11) - The system must support up to 500 concurrent users without performance degradation (
RR02) - Enable Cloud Run min-instances to avoid cold-start latency if fast response times are critical
Availability
- Target system availability: 99.9% (
RNF04) - Recovery from failure in under 5 minutes without data loss (
RNF05) - Enable Cloud SQL automated backups and point-in-time recovery
- Configure Cloud Run health checks against a
/actuator/healthendpoint
Monitoring
- Enable Google Cloud Monitoring and Logging for Cloud Run and Cloud SQL
- Set up uptime checks and alert policies for the backend service URL
- Monitor bundle sizes at build time — the
ng buildbudget configuration inangular.jsonwill fail the build if the initial bundle exceeds 1 MB