Configuration
This guide covers all configuration options available when creating and managing Ignite applications. Understanding these settings helps you optimize your application's performance, resource usage, and deployment behavior to match your specific requirements.
General Settings
Display Label: The human-readable name shown throughout the Viduli console interface. This can be updated at any time to reflect changes in your application's purpose or branding.
Resource Name: A unique identifier for your application within the project. Once created, this name cannot be changed as it's used internally for resource management and networking. Choose a descriptive name that clearly identifies your application's function.
Build Configuration
Repository: The GitHub repository containing your application source code. Ignite will automatically pull code from this repository for building and deployment.
Framework: Select the framework that matches your application technology. This is crucial as Ignite automatically configures build commands and optimizes deployment based on your selection. See our supported frameworks guide for the complete list of available options.
Expose Port: The port number on which your application serves requests. This tells Ignite how to route traffic to your application instances.
Root Directory: The directory within your repository that contains your application's source code. All build commands will be executed from this directory as the working directory.
Install Command: The command used to install your application's dependencies. This runs first during the build process to set up the required packages and libraries.
Build Command: The command that compiles or builds your application after dependencies are installed. This prepares your application for production deployment.
Output Directory: The location of your compiled application relative to the root directory. Only the contents of this directory will be included in the runtime container. This option is available for frameworks that require a build step.
Run Command: The command executed when your container starts, responsible for launching your application. This command runs relative to the output directory and should start your application server or main process.
Compute Resources
CPU Allocation: The amount of CPU resources allocated to each application instance. CPU can be allocated in fractional units called millicpu, where 1000 millicpu equals 1 full vCPU core. The minimum allocation is 125m (equivalent to 12.5% of a CPU core).
Memory Allocation: The amount of RAM allocated to each application instance. Memory is specified in standard units (MB, GB) with a minimum allocation of 256mb.
Efficient Resource Usage: Unlike traditional cloud VMs where you allocate resources for the entire operating system, Ignite only requires resources for your application itself. For reference, a basic Node.js application typically runs efficiently with just 125m CPU and 256mb RAM.
Scaling Configuration
Scaling Mode: Determines whether your application scales within a single region or across multiple regions. During the beta period, only single-region scaling is available.
Deployment Region: The geographic region where your application will be deployed. This affects latency for your users and data residency requirements.
Minimum Instances: The number of application instances that remain running during idle periods. This ensures your application can handle baseline traffic without cold start delays.
Maximum Instances: The upper limit for automatic scaling. Your application will scale up to this number of instances under full load to handle traffic spikes.
Auto-scaling Triggers: Scaling is automatically triggered when CPU utilization reaches 80% or memory utilization reaches 80%, ensuring your application maintains optimal performance under varying load conditions.
Networking Configuration
Service Mesh Address: The internal address used for communication within your project's service mesh. This address is automatically generated and cannot be modified, ensuring consistent internal networking across your application ecosystem.
Public Access: Enable this option to make your application accessible through the project's public API gateway. When disabled, your application is only reachable through the internal service mesh.
Path Prefix: Define the URL path pattern that should route requests to your application. Requests matching this prefix will be forwarded to your application instances. For example, setting /api/users will route all requests starting with that path to your application.
Prefix Rewrite: Optionally modify the request path before it reaches your application. This allows you to maintain clean external URLs while adapting to your application's internal routing structure. Leave blank to forward the complete matched path unchanged.
Example:
Suppose your external API path is /api/users, but your application expects requests to start with /users internally. You can set the Path Prefix to /api/users and the Prefix Rewrite to /users. This will rewrite incoming requests as follows: