Skip to main content

Documentation 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.

Deploying BodegaX to a production environment involves three independent layers: the static Angular frontend (generated as a 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.
The BodegaX Angular source code contains hardcoded http://localhost:8080 URLs in every component that makes HTTP requests — including history.component.ts, home.component.ts, login.component.ts, management.component.ts, register.component.ts, settings.component.ts, despachar-caja.ts, recibir-caja.ts, and terminar-jornada.ts. If you build and deploy without replacing these URLs, your production frontend will attempt to call a local development server that does not exist in the cloud environment. Every http://localhost:8080 reference must be updated to your production backend URL before running ng build.
The cleanest long-term fix for the hardcoded URL problem is to introduce Angular environment files. Create src/environments/environment.ts for local development and src/environments/environment.prod.ts for production, then replace every hardcoded base URL in component files with a reference to environment.apiUrl. Because angular.json sets "defaultConfiguration": "production", a bare ng build already uses the production configuration. You can wire up fileReplacements in angular.json so the production build substitutes environment.prod.ts for environment.ts automatically. This eliminates the need to manually edit component files for each deployment target.
// src/environments/environment.ts
export const environment = {
  production: false,
  apiUrl: 'http://localhost:8080'
};

// src/environments/environment.prod.ts
export const environment = {
  production: true,
  apiUrl: 'https://api.yourdomain.com'
};
Then in any component:
import { environment } from '../../../environments/environment';
// ...
this.http.get(`${environment.apiUrl}/productos/all`)

Frontend Deployment

Running ng 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/.
# Build for production
ng build
The 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 is the simplest deployment option for the Angular frontend and integrates natively with Google Cloud.
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.
# Install Firebase CLI if not already installed
npm install -g firebase-tools

# Authenticate and initialize the project
firebase login
firebase init hosting
# When prompted, set the public directory to: dist/bodega-x-angular
# Configure as single-page app: Yes
# Set up automatic builds with GitHub: Optional
# firebase.json is created by this command — it does not ship with the repo

# Build and deploy
ng build
firebase deploy
Firebase Hosting automatically provisions a CDN, global edge caching, and a free SSL certificate. The 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 set spring.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.
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.
# Dockerfile — create this file in the backend project root
FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
COPY target/*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]
# Build the JAR
mvn package -DskipTests

# Build and push the Docker image to Artifact Registry
gcloud builds submit --tag gcr.io/YOUR_PROJECT_ID/bodegax-backend

# Deploy to Cloud Run
gcloud run deploy bodegax-backend \
  --image gcr.io/YOUR_PROJECT_ID/bodegax-backend \
  --platform managed \
  --region us-central1 \
  --set-env-vars SPRING_DATASOURCE_URL=jdbc:postgresql:///bodegax?cloudSqlInstance=YOUR_CONNECTION_NAME \
  --set-env-vars SPRING_DATASOURCE_USERNAME=your_db_user \
  --set-env-vars SPRING_DATASOURCE_PASSWORD=your_db_password \
  --allow-unauthenticated

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.

The following steps cover the complete end-to-end GCP deployment — the path described as recommended in the BodegaX technical documentation.
1

Prepare Your GCP Project

Create or select a GCP project and enable the required APIs:
gcloud config set project YOUR_PROJECT_ID

gcloud services enable \
  run.googleapis.com \
  sqladmin.googleapis.com \
  artifactregistry.googleapis.com \
  cloudbuild.googleapis.com \
  firebase.googleapis.com
2

Provision Cloud SQL (PostgreSQL)

Create a Cloud SQL PostgreSQL 14 instance and a dedicated database for BodegaX:
# Create the Cloud SQL instance
gcloud sql instances create bodegax-db \
  --database-version=POSTGRES_14 \
  --tier=db-f1-micro \
  --region=us-central1

# Create the database
gcloud sql databases create bodegax --instance=bodegax-db

# Create a database user
gcloud sql users create bodegax_user \
  --instance=bodegax-db \
  --password=your_secure_password
Note the connection name for your instance (formatted as PROJECT:REGION:INSTANCE). You will need it when deploying to Cloud Run.
3

Update the API Base URL in Angular Source

Before building the frontend, replace every hardcoded 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:
export const environment = {
  production: true,
  apiUrl: 'https://bodegax-backend-HASH-uc.a.run.app'
};
If you have not yet introduced environment files, perform a find-and-replace across the src/ directory:
# Preview all occurrences
grep -r "http://localhost:8080" src/ --include="*.ts"

# Replace with your Cloud Run backend URL
find src/ -name "*.ts" -exec sed -i \
  's|http://localhost:8080|https://your-cloud-run-url|g' {} +
4

Build the Angular Frontend

Generate the production build of the Angular app:
ng build
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).
5

Deploy the Frontend to Firebase Hosting

Initialize Firebase Hosting — the BodegaX repository does not include a firebase.json, so firebase init hosting must be run once to create it. Answer the interactive prompts as shown below, then deploy:
firebase init hosting
# Public directory: dist/bodega-x-angular
# Configure as single-page app: Yes
# (firebase.json is created by this command)

firebase deploy --only hosting
Firebase Hosting provides an automatic SSL certificate and a global CDN. The deployed URL will be https://YOUR_PROJECT_ID.web.app.
6

Containerize and Push the Spring Boot Backend

Build the Spring Boot JAR, then build and push the Docker image to Google Artifact Registry:
# Package the backend JAR
mvn package -DskipTests

# Create an Artifact Registry repository
gcloud artifacts repositories create bodegax \
  --repository-format=docker \
  --location=us-central1

# Build and push using Cloud Build
gcloud builds submit --tag \
  us-central1-docker.pkg.dev/YOUR_PROJECT_ID/bodegax/backend:latest
7

Deploy the Backend to Cloud Run

Deploy the container to Cloud Run with the Cloud SQL connection and environment variables:
gcloud run deploy bodegax-backend \
  --image us-central1-docker.pkg.dev/YOUR_PROJECT_ID/bodegax/backend:latest \
  --platform managed \
  --region us-central1 \
  --add-cloudsql-instances YOUR_PROJECT:us-central1:bodegax-db \
  --set-env-vars "SPRING_DATASOURCE_URL=jdbc:postgresql:///bodegax?cloudSqlInstance=YOUR_PROJECT:us-central1:bodegax-db&socketFactory=com.google.cloud.sql.postgres.SocketFactory" \
  --set-env-vars "SPRING_DATASOURCE_USERNAME=bodegax_user" \
  --set-env-vars "SPRING_DATASOURCE_PASSWORD=your_secure_password" \
  --set-env-vars "SPRING_JPA_HIBERNATE_DDL_AUTO=validate" \
  --allow-unauthenticated
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.
8

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:
gcloud run services logs read bodegax-backend --region us-central1 --limit 50
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=none or validate — never create or update in 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/health endpoint

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 build budget configuration in angular.json will fail the build if the initial bundle exceeds 1 MB

Build docs developers (and LLMs) love