Skip to content

Frequently Asked Questions

Who is behind the development of the Coldtivate app?

The Coldtivate app has been developed as part of the Your Virtual Cold Chain Assistant (yourvcca.org) initiative since 2021. As of January 2026, the project involves three main partners:

  • BASE Foundation (Swiss non-profit organization): Initiated the Coldtivate project, owns the vision and strategic direction, and ensures alignment with global sustainability goals.
  • Empa (Swiss Federal Laboratories for Materials Science & Technology): Is the Research & development partner, provides scientific validation, modeling, and simulations, developed the shelf-life models, and collaborates on data-driven insights.
  • Mosano: Is the software engineering partner, currently responsible for full-stack development (backend, mobile), implements scalable infrastructure & CI/CD pipelines, and provides ongoing maintenance and technical guidance.

What are the four main layers of the Coldtivate architecture?

Coldtivate's system is organized into four main layers:

  • Frontend: React Native app and Knowledge Hub for end users.
  • Backend Monorepo: Core services orchestrated by the Base API, including Impact Dashboard, Farmer Dashboard, and App Impact Reporting, Machine Learning (ML) forecasting, and digital twin simulations.
  • Database: PostgreSQL as the primary store for application and analytics data.
  • Computational Model: Digital Twin and COMSOL Runtime for advanced simulation tasks.

Where is the Coldtivate code located and what are the main repositories?

The codebase is available open source at https://gitlab.com/b1866/coldtivate and is organized across several key repositories:

  • Backend Monorepo: @coldtivate/backend-monorepo (Core backend services, APIs, integrations, and business logic).
  • Mobile App (React Native): @coldtivate/mobile-app-react-native (The cross-platform user-facing application for Android and iOS).
  • Knowledge Hub (PWA): @coldtivate/knowledge-hub-pwa (A progressive web app offering comprehensive resources and collaboration tools).
  • Documentation: @coldtivate/docs.coldtivate.org (Our centralized portal for all technical documentation and user guides).

Which external services integrate with Coldtivate?

Coldtivate integrates with a suite of essential external services:

  • Monitoring & Reliability: Sentry (tracks application errors and performance issues).
  • Communication: Twilio (enables SMS notifications for farmers and traders) and SendGrid (manages email delivery for reports and alerts).
  • Payments: Paystack (a robust payment gateway for marketplace transactions in Nigeria).
  • Simulation & Modeling: COMSOL Multiphysics Runtime (executes complex Digital Twin simulations).
  • Temperature Monitoring: Sensors by Ecozen, Victron Energy, Figorr, and Ubibot are currently integrated into Coldtivate to capture temperature, energy, and operational data in near real time.

What are the benefits of Coldtivate for developers?

The benefits include:

  • It is Open-source (MIT License): Free to adapt, extend, and integrate into your own systems.
  • Flexible Integration: Can be integrated into existing systems (ERP, dashboards, cold transport).
  • Multi-language Support: Supports 10+ languages (including French, Hindi, Arabic) for global reach.
  • Open-Source Incubator Support: Helps with tailoring and scaling custom solutions.

What is the system architecture that Coldtivate uses?

The Coldtivate platform is built on a scalable, containerized service architecture. This design ensures modularity, high availability, and efficient resource utilization. This architecture comprises:

  • Services (Microservices): Backend API, App Impact Reporting, Farmer Dashboard, Impact Dashboard, ML4market, and COMSOL, which run as separate, isolated containers.
  • Gateway (Caddy): The only public endpoint, which functions as a reverse proxy and handles TLS, CORS, routing, and optional load balancing for all incoming requests.
  • Infrastructure (State Management): PostgreSQL + PostGIS (for data persistence with robust volumes and backups) , Redis/Valkey (serves as cache and Celery queues) , and the Celery Worker (for asynchronous tasks).

Why is it important for the local development environment to mirror production?

Your development environment runs the identical containerized services (API, dashboards, ML, COMSOL-DT) as production. This ensures:

  • Easier Debugging: Issues encountered locally can be reproduced and traced using the same methodologies as in live production systems.
  • Safer Deployments: The consistent environment helps catch configuration discrepancies and potential issues before they reach production users.
  • Scalable from Day One: The same robust container model and Docker Compose setup is utilized across Local, Staging, and Production, ensuring predictable performance.

What are the essential software prerequisites for local setup?

You need to have the following installed:

  • Docker Desktop: For container management.
  • Pipenv: To manage your Python virtual environment and dependencies.
  • Node.js (v18 or later) & Yarn: For JavaScript dependencies.
  • Optional: Install Xcode (requires Cocoapods) or Android Studio (requires OpenJDK) if you want to build and run the React Native mobile app locally on a real device or simulator.

What are the initial steps to prepare the code?

You should fork (acquire the codebase) of the necessary repositories from GitLab : backend-monorepo , mobile-app-react-native , and knowledge-hub. For environment variables, copy .env.example to .env and customize the .env file for your local machine's specifics.

How do I start the backend and core services (minimal setup)?

Navigate to the backend-monorepo directory. Run the custom local deployment script: ./scripts/environment-deployment-management.sh deploy to start all backend services in detached mode.

How do I get the mobile application (frontend) running?

In the mobile-app-react-native directory:

  • Run yarn install to fetch dependencies.
  • Execute yarn start to launch the development server.
  • Finally, you can run yarn ios to build and launch the app on the iOS simulator, or yarn android to do the same on Android (requires a simulator/emulator to be installed and running).

What should I do if the Docker containers fail to start?

Try running ./scripts/environment-deployment-management.sh compose down to remove the containers , then redeploy with ./scripts/environment-deployment-management.sh deploy. Also, ensure Docker Desktop is running and stable.

How do I resolve port conflicts or clear out stale containers?

Run docker system prune -af. This command removes all unused containers, networks, images, and the build cache, but it should be used with caution.

The frontend cannot communicate with the API. What should I check?

Confirm the .env file uses http://localhost:<port>. Also, check docker compose ps to confirm the correct API port is exposed and running.

The backend build process requires a significant amount of free disk space. How can I manage this requirement?

This is a common issue due to the size of all container images. You can free up space by clearing user caches and code-related temporary files. Additionally, instead of building the entire monorepo, you have the option to build only the Base API container to save significant disk space and memory.

Is there a way to exclude specific services, like the COMSOL Digital Twin, from the local build to further save resources?

Yes, this is a feature that was actively discussed during the session and is a planned improvement. The suggestion is to add a new command to the deployment script (e.g., ./scripts/environment-deployment-management.sh deploy --exclude-comsol) that allows you to deploy everything except the COMSOL service. Community contributions for implementing this feature are welcome.

Can I run services one by one to manage resource usage, or do they all need to start at once?

While services can be managed individually using Docker Compose, most core services (like the dashboards and APIs) are dependent on the database. It's generally recommended to use the deployment script to start the essential services in a controlled way. You can modify the docker-compose.yml to run only the services you are actively working on, ensuring the database is always started first.

Where can I find the contribution guidelines, and what is the process for submitting a Pull Request (PR)?

The detailed Contribution Guidelines are available at https://docs.coldtivate.org/contributing/. They cover everything from forking the repository and branching strategy to coding standards and the PR review process.

I am encountering issues with the seeding script, specifically with check-ins. What data is missing?

The issue is likely due to missing testing data in the database. To enable full functionality, including check-ins in the backend, you need to seed the storage_crop table with initial data. This can be done by executing simple SQL commands. An action item was created to add this specific table to the seeding script.

Do I need to report issues I face while building the mobile app?

Yes, please report any issues you face during the mobile app build process at [email protected], as this feedback helps the team identify common setup blockers. Ensure you have GDK 17 installed for Android emulator builds, as this is a specific prerequisite.

How is the Coldtivate Base-API structured, and what are the main application modules?

The Base-API is organized into separate Django applications (apps) and shared modules to ensure clarity and separation of concerns. Key apps include:

  • Marketplace: Handles trading, carts, orders, and payments.
  • Operation: Manages crate operations, stock movements, and surveys.
  • Prediction: Contains ML models, price forecasting, and market data logic.
  • Security: Manages roles, permissions, and access control.
  • Storage: Deals with cold rooms, inventory, sensors, and capacity.
  • User: Handles authentication, profiles, and organization management.

Where are the database models defined in the codebase, and what are some key models?

All Django ORM models that define the database structure are located in the core/apps/<app_name>/models.py file for each respective application. Core models include: User (Operator, Farmer, ServiceProvider), Company, CoolingUnit, Crate (which has a many-to-one relationship with CooligUnit), Movement, Order (Marketplace), etc.

Does Coldtivate handle geospatial data, and if so, how?

Yes, Coldtivate uses PostGIS, an extension for the PostgreSQL database, to manage and query geospatial data. This is essential for features like tracking locations and defining area polygons (e.g., cold room zones).

What is the flow of a request through the Django REST Framework (DRF) API?

The standard flow follows this pattern: Model (Database definition) -> Serializer (Data conversion/validation) -> View (Business logic implementation) -> Router (URL mapping) -> Endpoint (API accessible URL).

What is the primary role of Django Rest Framework (DRF) Serializers?

Serializers act as the data transformation layer. They convert complex data types, like Django model instances, into native Python data types (that can be easily rendered into JSON/XML) and vice versa. They are also responsible for data validation before saving to the database. They are located in core/apps/<app_name>/serializers.py.

How is API versioning managed in Coldtivate?

Coldtivate uses URL-based versioning (e.g., /api/v1/..., /api/v2/...). This is the clearest and most flexible method, allowing clients to explicitly choose the version they interact with. Version control is managed by organizing endpoints within versioned URLs in the main urls.py file.

How does Coldtivate handle user Authentication and Authorization?

Authentication is handled using JSON Web Tokens (JWT), providing a stateless and secure way for users to access the API after initial login. Authorization (what a user can do) is managed through Django Rest Framework Permissions and is primarily driven by Roles assigned to the user.

What is the process for making changes to the database schema?

All database schema changes are managed via Migrations to ensure consistency. The process is: modify the model in models.py -> run manage.py makemigrations (to generate the migration script) -> run manage.py migrate (to apply the changes to the database). Best Practice: The team suggests Squashing Migrations before deployment to production environments to keep the project history clean and manageable.

How does Coldtivate manage multi-language support (Localization)?

Coldtivate provides robust localization using standard .po files for translation sources, which are compiled into efficient .mo files for production. The translation files are centrally located in the locale/ folder at the root of the Base-API. The Docker build process automates the compilation of these message files using manage.py compilemessages during Continuous Integration (CI). The platform supports over 10 languages, including Arabic, French, Gujarati, Hausa, Hindi, Igbo, Odia, Portuguese, Yoruba, and English.

What is the difference between System-Level and User-Level Integrations?

System-Level Integrations (e.g., Sentry for error tracking, Twilio for SMS) are managed entirely by the backend and use static credentials stored in environment variables. User-Level Integrations (e.g., payment gateways like Paystack) are managed by the end user/organization. They require specific models to store user-provided credentials or API tokens, enabling a multi-tenant approach to external services.

What is the difference between the 'Generic' and 'Detailed' Digital Twin models mentioned in the session?

Generic Digital Twin models are simplified representations of crops, where each crop is approximated by a single point. Each crop type has its own corresponding model. Detailed Digital Twin models offer a more accurate representation of specific crops, where the full geometry is taken into account. Currently, these models are available for bananas, tomatoes, apples, and potatoes. All the other 22 supported fruits and vegetables are modelled using the generic digital twin.

Where can I find out more technical and scientific details about the Digital Twin models?

We recommend watching this video and contacting us at [email protected] in case of additional questions.

What are the main backend modules developed by BASE and Empa, and what is their function?

The additional modules focus heavily on data analytics and impact reporting:

  • Farmer Dashboard: Aggregates and exposes key metrics relevant to cold storage operations and the environmental impact for individual farmers/users.
  • Impact Dashboard: Displays similar information but at the company or organizational level, providing transparency and metrics for registered employees and operator accounts.
  • Machine Learning Models: These are the models used for price forecasting in countries like Nigeria and India.
  • App Impact Reporting: Allows users with the necessary permissions to download and manipulate raw data, offering additional insights beyond the standard dashboards.

There seems to be some confusion regarding the terminology for user roles. What is the standard convention we should use?

The original naming convention used "farmers". However, as the application grew and the Marketplace feature was introduced, it became an inaccurate label, because the same role was now being used for consumers who might not be farmers at all. To establish clarity across the app and code, the suggested uniform naming convention is to use "cooling users", "operators”, and "registered employees". This distinction ensures everyone understands who is a basic system user versus an internal organizational member.

How do I add a new language, like Italian, to the backend?

Adding a new language is a step-by-step process:

  • Create the directory structure for the new language (e.g., locale/it).
  • Copy the existing translation files (.po) into this new directory.
  • Modify the message strings in the new .po file for the new language.
  • Update the user model in the Django application to include the new language as an option.
  • Create and run a database migration to apply the change to the database.
  • Note: The translation files (.po into compiled .mo files) are automatically compiled during the Docker container build process, so you generally don't need to manually run manage.py compilemessages.

I am interested in contributing translations. What is the process, and are there specific languages needed?

The core team strongly encourages community contributions to localization. It is considered an excellent first step for new contributors to familiarize themselves with the codebase. You are welcome to contribute any native language not currently supported.

How is the React Native codebase organized within the src/ directory?

The src/ directory follows a modular structure to separate concerns:

  • screens: Contains high-level components corresponding to navigation routes.
  • ui: Contains reusable UI elements (e.g., buttons, selectors).
  • navigation: Defines the app's navigation stacks and flows.
  • stores: Holds the Zustand stores used for state management.
  • services: Encapsulates business logic and external service interactions.
  • i18n: Contains all localization files.

Which tool is used for styling the mobile application?

The mobile application uses Tailwind CSS for styling, which allows for rapid, utility-first UI development by leveraging pre-defined CSS classes.

Which tools are used for state management in the application?

Coldtivate uses Zustand for state management. It provides a lightweight, minimal, and highly flexible global store without the boilerplate typically associated with Redux-style solutions.

What is the main advantage of using Zustand?

Zustand offers a simple and intuitive API that makes state management easy to reason about. It avoids reducers, actions, and complex setup, while still supporting scalable patterns.

How is persistent and secure local data storage handled on the frontend?

For fast, secure, and persistent local storage, Coldtivate uses MMKV. This is used to store critical, non-sensitive data such as the user's authentication token and language preferences.

How does the application handle navigation between different parts of the app?

The app uses React Navigation and organizes the interface into multiple Stacks (e.g., AuthStack, MainStack). The main router checks for the authentication token stored in MMKV to dynamically switch between the public AuthStack (login screens) and the protected MainStack (core application screens).

How is localization implemented on the frontend, and what are its key features?

Localization is handled using the i18next framework with the react-i18next integration. Key features include:

  • Automatic detection of the user's device locale with intelligent fallback.
  • Secure storage of the user's preferred language in MMKV.
  • Automatic handling of RTL (Right-to-Left) layouts for languages like Arabic.

What are the primary areas identified for continuous improvement in the frontend architecture?

The core team has identified three key areas for future contributions and enhancement:

  1. Error Handling: Implement clearer, user-friendly error messages and add auto-retry/graceful fallback strategies.
  2. Offline Experience: Expand offline-first workflows, improve conflict resolution, and make the offline state more visible in the UI.
  3. Quality & Monitoring: Expand End-to-End (E2E) testing coverage and strengthen crash reporting and analytics tools.

What is the Coldtivate Knowledge Hub, and how is it integrated into the mobile app?

The Knowledge Hub is an external Progressive Web App (PWA) that provides users with access to articles, resources, and content related to new functionalities and industry knowledge. It is integrated into the mobile app and is accessible via the burger menu (usually in the top left corner). When a user taps a Knowledge Hub link, the app constructs the final URL using:

  1. The base Knowledge Hub URL (from environment variables).
  2. The user's language preference (from local storage).

How does a contributor add new content to the Knowledge Hub and make it available in the mobile app?

To add new content, you first need to create the content within the Knowledge Hub PWA itself. To link it in the mobile app, you must modify the list item within the mobile app's repository (found under source > screens > dashboard > knowledge hub folders). This list item needs to specify the content type, URL, and route that navigates to the detail screen (which renders the web view).

How is the reCAPTCHA feature implemented in the mobile app, and where is it used?

reCAPTCHA is implemented to enhance application security and prevent bot activity. The reCAPTCHA service logic and the custom UI component are located in the services and components folders, respectively. A custom hook was created to simplify its integration into various parts of the app. It is currently integrated into:

  • All auth flows (sign-up/login).
  • The password recovery screen.
  • The management screen (during the process of inviting operators and registered employees).

How are errors handled on the frontend, and what improvements are needed?

Errors are caught in the HTTPClient.ts file and thrown as custom error objects using an error utility function. They are also logged to the console or sent to Sentry for crash reporting. The main area for improvement is error messaging. While errors are caught, the messages provided to the user are not always helpful. An action item was created to improve the error handling by providing more informative and user-friendly error messages.

Are all error messages localized?

No. Errors that are logged to the console or sent to Sentry for debugging are kept in English. Only user-facing error messages (messages that the end-user sees in the UI) are being localized.

What are the three main environment architectures Coldtivate uses, and what is the purpose of each?

Coldtivate utilizes three distinct environments:

  1. Local: A developer's personal workspace for immediate feedback, rapid iteration, and safe experimentation without affecting others. It's where the code is born.
  2. Staging (Pre-Production): A near-identical replica of the production environment. It is used for comprehensive Quality Assurance (QA), testing, and client reviews. Its main purpose is to ensure features work exactly as expected before the launch.
  3. Production (Prod): The live system that end-users interact with daily. Stability and reliability are the absolute top priorities in this environment.

What is the primary difference between Staging and Production in terms of setup?

Both environments are set up to be identical regarding the technology stack, services, and infrastructure (IaaS, PaaS, DBs, Storage). The key difference lies in the data, third-party environments, and cost:

  • Staging uses test data/dummy data and may point to sandbox third-party API accounts (zero or low cost).
  • Production uses real user data and points to live, active third-party API accounts (real cost).

How are environment-specific configurations managed in the Backend (Django)?

The Django Backend uses a hierarchical configuration system based on Python files:

  • A base configuration file (settings.py) holds most common settings.
  • Environment-specific files (e.g., staging.py, production.py) inherit the base settings and then override only the specific configurations (e.g., setting DEBUG=False, or using external API URLs) based on the target environment.

How are environment variables (secrets) securely injected into Staging and Production?

Environment variables are the primary way to inject secrets (API keys, DB credentials, etc.).

  • Local: Uses local .env files loaded by Docker Compose/Pipenv.
  • Staging/Production: Utilizes Gitlab Variables for secrets management. These secrets are injected into the environment during the Continuous Integration/Continuous Deployment (CI/CD) pipeline process.

What is the process and best practice for applying database Migrations across environments?

Database schema changes are managed via Django Migrations:

  1. The developer creates model changes and generates a migration file locally (makemigrations).
  2. The generated migration file is committed to the source code.
  3. During deployment, the Docker Entrypoint script automatically executes the manage.py migrate command to apply the latest migrations to the target database (Staging or Production).

Best Practice: Migrations must be backward compatible. This ensures the old code version can continue to function with the new data structure while the new deployment is underway, guaranteeing Zero Downtime.

Which tools are used to monitor the health and performance of the Staging and Production environments?

Coldtivate Sentry for error tracking and Application Performance Monitoring (APM).

What are the main areas identified for future improvement in the deployment processes?

The team has outlined the following enhancements:

  • Automate .env Sync: Create tools to automatically synchronize .env files between environments, reducing human error and ensuring configuration consistency.
  • Optimize Container Build Times: Implement strategies like layer caching and parallelization to significantly speed up the CI/CD pipeline.
  • Expand Staging Testing: Include more robust integration and performance tests in staging before any deployment is approved for production.
  • Implement Dedicated Secrets Management: Move away from simple .env files to dedicated secrets management tooling for long-term security.

What is the high-level release flow for deploying code to Production?

The production release follows a structured, multi-step process to ensure stability:

  1. Code Merge & PR: A developer creates a feature branch, opens a Pull Request (PR) which is reviewed, and then merged into the main development branch.
  2. Pipeline Trigger: The merge into the main branch triggers the automatic CI/CD pipeline.
  3. Backend Build & Deploy: The build jobs for the various backend services (Base API, Console, ML, dashboards) run in parallel. The deployment to Production is then manually triggered once all build jobs pass successfully.
  4. Frontend Release: The frontend release is triggered and tagged (a key difference from backend releases). The app is submitted to the Apple Developer Console or Google Play Console for review.
  5. Finalization: Once the app is approved by the stores, it is manually published. The backend deployment is completed, which includes a mandatory database backup before and after the deployment.

What is the main difference between the release processes for the Backend and Frontend?

The key difference is tagging: Every Frontend release is tagged before deployment, while Backend releases can be untagged or tagged. The Frontend also requires the additional, mandatory step of submitting the app for review to the external mobile application stores (Apple/Google).

How do developers visually confirm the status of the pipeline and diagnose failures?

Developers use the GitLab Pipelines page to see a visual representation of the entire CI/CD flow. They can view examples of successful and failed pipelines and navigate through the detailed job results to quickly diagnose and fix issues, such as an expired certificate warning mentioned in the session.

Why is it important to check the minimum app version during the Production Release flow?

Checking and updating the minimum app version is crucial because if a new backend feature requires an updated frontend to work correctly, setting a new minimum version ensures that users cannot access the app with an incompatible, older version.

What is the recommended strategy for deploying the Coldtivate application on a cloud platform?

Coldtivate is designed for deployment on any Infrastructure-as-a-Service (IaaS) platform (e.g., Azure, AWS, Google Cloud). The primary strategy is to use Docker Compose. The application stack is deployed as a collection of containerized services defined in the docker-compose.yml file, ensuring portability and consistency across environments.

How are Databases and File Storage managed in an IaaS environment?

  • Database (PostgreSQL/PostGIS): Databases are typically managed as separate services on the IaaS platform, ensuring they are independent of the compute containers. Crucially, they use persistent volumes to prevent data loss when containers are restarted or scaled.
  • File Storage (e.g., Azure Storage): User-uploaded files and media (such as crop images or reports) are stored in dedicated cloud storage services designed for durability and scalability. In Azure, this typically means Blob Storage. Application servers access these files directly via SDKs or REST APIs; they do not rely on container storage, which is ephemeral.

What are the main benefits of using a containerized approach (Docker) for cloud deployment?

The containerized approach ensures:

  1. Isolation: Each service runs in its own isolated environment.
  2. Consistency: The local environment mirrors the production environment, reducing "it works on my machine" issues.
  3. Portability: The entire stack can be moved between different cloud providers with minimal changes.
  4. Repeatability: Builds and deployments are consistent and can be easily reproduced.

What is the role of the CI/CD pipeline in the Coldtivate workflow?

The CI/CD pipeline automates the entire journey From Code to Cloud. It ensures a reliable, repeatable, and observable process that includes:

  • Automated Builds: Creating consistent Docker containers for all services.
  • Rigorous Testing: Running tests to validate code quality and functionality.
  • Seamless Deployment: Automating the release to Staging and Production.

What is the importance of End-to-End (E2E) Testing, and what tool is used?

E2E Testing is critical as it validates the application's core functionality by simulating real-world user flows across the entire stack (Frontend to Backend). Coldtivate uses Maestro for E2E testing, integrating it directly into the CI/CD pipeline to ensure core functionality is validated before any release.

What is the process for applying database migrations within the CI/CD pipeline?

Database migrations are a critical step in the deployment process. The Docker entrypoint script for the backend service (Base-API) is configured to automatically run the necessary database migration commands (manage.py migrate) before the new application code starts serving traffic.

How is the production environment monitored for errors and performance issues?

Sentry is the primary tool used for monitoring the application's logic and performance. It provides real-time visibility into application errors and app performance monitoring (APM), enabling the team to proactively identify and rapidly respond to bugs, memory leaks, and performance bottlenecks in the production environment.

How does the monitoring strategy ensure data quality between environments?

Environment Tags are used to distinguish data. Sentry is configured to include environment-specific tags (local, staging, production) with every error and performance trace. This ensures that reliable production monitoring data is not contaminated by noise from development or test environments.

What is the overall benefit of Coldtivate's unified development pipeline?

The unified pipeline ensures reliability and consistent quality by linking Code Development, Automated Builds, Testing (Maestro E2E), Seamless Deployment (CI/CD), and Proactive Monitoring (Sentry). It is designed to build trust through automation, visibility, and continuous iteration.

Why do the End-to-End (E2E) tests only run on Android in the CI/CD pipeline?

The E2E tests are implemented using the Maestro library. Currently, the Linux-based CI/CD runners used in the pipeline only support Android emulation. Therefore, the automated E2E tests are focused solely on the Android platform.

Does this mean Coldtivate is not tested on iOS?

Local testing on iOS is still possible and necessary, but the automated E2E tests do not run for iOS in the CI/CD pipeline. This poses a small risk, especially for features specific to the iOS platform. The team suggests exploring options like using dedicated Mac build agents to support both Android and iOS simulators in the CI/CD pipeline in the future.

What challenges were faced when setting up E2E tests for both platforms initially?

Inconsistencies were found between Android and iOS, particularly with commands like the "hideKeyboard". On iOS, this command often resulted in random taps or selecting the wrong input field. This required integrating custom tab actions to reliably close the keyboard and make the tests stable on both platforms during local testing.

What is the recommended deployment strategy for organizations with varying traffic or internet reliability?

The recommended deployment strategy depends heavily on the expected traffic:

  • For low traffic scenarios, a single instance is sufficient and cost-effective.
  • For high traffic or mission-critical scenarios requiring high uptime, a highly available solution with multiple instances and load balancing would be necessary.

Can Sentry be self-hosted, or do I need to use their cloud service?

Sentry does offer a free tier for its cloud-based service, and it can also be self-hosted. An action item was logged to investigate self-hosting Sentry as an alternative to the current cloud-based deployment.

Where can I find a walkthrough of the mobile application's screens and features?

A detailed resource called the "Onboarding Kit" is available. This is a website with recorded video tutorials that show the full flow of different features within Coldtivate, which is helpful for understanding the platform's functionality.

How can Coldtivate and similar Open-Source platforms achieve sustainability and recover costs over the long term?

Long-term sustainability is achieved through a Balanced Monetization model focused on cost recovery rather than high-profit generation. Strategies include:

  1. Value-Added Services: Charging for premium services that use the Open-Source core (e.g., dedicated technical support, 24/7 monitoring, certification, and specific hardware integration).
  2. Hybrid/Open-Core Models: Keeping the core codebase Open-Source while offering advanced features, custom dashboards, or specific machine learning models as a paid offering.
  3. Partner Support: Receiving funding from strategic partners and grants, especially those aligned with sustainability and impact goals.

What is the estimated total monthly cloud hosting cost, and what are the primary cost drivers in the Azure infrastructure?

The total estimated monthly cost in the base configuration, for one cooling unit, is about $73. The cost distribution shows that the largest factors are:

  1. Virtual Machines (VM): The most expensive component (approx. 63.6% of total cost), providing the computing power for containers and services.
  2. Azure Database for PostgreSQL: The second-highest cost (approx. 28.8%), required for persistent data storage.

Which are the recommended configurations to minimize hosting costs?

We recommend the following configurations:

  • Minimum Configuration:
    • 2 core
    • 4GB RAM
    • 8GB Swap Memory
  • Recommended Configuration:
    • When running the database in the same instance: 16GB RAM and Swap Memory, 4vCPU - Depends on traffic/usage.
    • With an external database: 8GB RAM and Swap Memory, 4vCPU - Depends on traffic/usage.

Some Azure instances have a local ephemeral disk that can be used and is mounted under `/mnt`. You could create a swapfile under that disk.

What are the main strategies for optimizing cloud costs and application performance?

  1. Resource Monitoring: Use tools like Azure Insights to track CPU, RAM, and I/O usage, and adjust VM scaling (right-sizing) based on actual need.
  2. Query Optimization: Refine database queries to reduce execution time, lowering the database cost.
  3. Log and Caching Management: Efficiently manage logs and utilize caching services (Redis/Valkey) to reduce the load on VMs and the primary DB.

Which application component generates a significant recurring expense, and what are the alternatives?

The use of Twilio for sending SMS alerts is a significant recurring expense. Alternatives to reduce costs include: Messagebird, Sinch, Plivo, etc.

How is the long-term maintenance and sustainability of an Open-Source platform like Coldtivate planned?

Sustainability is built on three pillars:

  1. Proactive System Maintenance: Implementing continuous monitoring (Sentry) for immediate feedback, automated testing (E2E) to prevent regressions, and a regular patching/dependency update strategy.
  2. Resource Management: Ensuring that infrastructure costs are covered by the established monetization model.
  3. Community Engagement: Fostering an active developer community to share the maintenance workload, introduce new features, and ensure the code evolves.

Are there any cost-effective alternatives to SMS alerts for user communication?

Yes. The team advised exploring:

  • Push notifications: A cost-effective alternative, provided the user base has access to smartphones.
  • WhatsApp Business API integration: Also a strong alternative, provided smartphone penetration is high among the user base.

Does the Coldtivate application require a COMSOL license to run the Digital Twin simulations?

No. The COMSOL Multiphysics executable used for predicting produce shelf life is part of the application and can be used without needing an official COMSOL license. The executable is packaged in a way that allows anyone to run it for the purpose of the application.

What is the purpose of the COMSOL executable included in the application?

The executable contains models for 26 types of fruits and vegetables and is used to predict their shelf life based on sensor data and environmental conditions.

How does the level of farmer technology adoption impact the application's communication strategy?

Insights from pilot programs show that many farmers, especially in rural areas, do not own smartphones. This emphasizes the importance of understanding the technological state of the target audience when choosing communication methods. For users without smartphones, the application must rely on text messaging (SMS alerts) or other simple, non-internet-dependent communication methods for critical information.

Is the hosting cost per cold storage unit fixed or variable?

The cost per cold storage unit is highly variable and difficult to estimate accurately as it depends on factors like location, operational efficiency, and specific technology implementation.