Runtime operations

1. 01
   Choose a deployment source

   Open an app and select Deploy. Enter a branch or immutable Git ref. Use an immutable commit SHA when you need a reproducible release. Automatic deployments use the app's configured branch only when continuous deployment is enabled and the GitHub App can access the repository.

2. 02
   Watch build and runtime state

   Deployment history shows the build status. After a successful build, the container starts on the app instance. The app must bind to the configured port and respond with HTTP 2xx from /.

3. 03
   Verify the release

   Confirm deployment status succeeded, then open the app hostname. Select Tail logs to refresh the latest 500 container lines every three seconds. Select Stop tail to retain the current snapshot, or Close to stop and remove it. Use the output to confirm the process started with the expected environment and did not exit after the health check.

4. 04
   Start, stop, or restart the runtime

   Start creates or resumes the app instance. Stop shuts it down. Restart restarts the application container through the control plane. A stopped app can retain queued environment changes; it cannot receive a live container update until it is running.

1. 01
   Add or replace a variable

   Open the app, select Environment, enter the key and value, and save. Use a key format accepted by the application runtime, such as DATABASE_URL or API_TOKEN.

2. 02
   Wait for delivery

   For a running app, Astroscale writes the encrypted environment document and restarts or updates the runtime target as needed. For a stopped or transitioning app, the update stays queued until the target can accept it.

3. 03
   Verify application behavior

   Confirm that the variable reports delivered, then restart or deploy when the application reads settings only at process startup. Validate through the application health endpoint or logs; never validate by printing a secret.

4. 04
   Remove an unneeded variable

   Delete the key from Environment and confirm delivery. Re-deploy or restart if the application caches configuration at startup.

Reserved public IP

1. 01
   Enable or disable it in App configuration

   Enable Reserved IP when a stable public IPv4 is required. Enablement checks the Regional Elastic IP quota before CloudFormation requests an address. Disable it when the app does not need a fixed address.

2. 02
   Wait for the infrastructure transition

   The app enters transitioning. When disabling, Astroscale disassociates and releases the EIP to prevent an unused-address charge. When enabling, it associates the allocated address with the app instance.

3. 03
   Verify DNS after a non-reserved restart

   Without an EIP, an EC2 stop/start can change the public IPv4 address. The control plane reconciles the Route 53 record after the app returns. Confirm the hostname, not a previously observed IP address.

Public ingress and private service routes

1. 01
   Add public ingress only when required

   Open Network controls and add the exact TCP port and IPv4 CIDR. Use the smallest CIDR possible. Ports 80 and 443 remain owned by the managed HTTPS proxy and cannot be reassigned.

2. 02
   Create a private app-to-app route

   Select a running source app and a running destination app in the same AWS account and Region. Astroscale creates a security-group rule that permits the source to reach the destination's internal listener on TCP 8080.

3. 03
   Configure the source application

   Use the private hostname shown for the destination and connect to port 8080. Do not use the destination public hostname for an internal service dependency.

4. 04
   Remove access when the dependency ends

   Delete the private route. Astroscale revokes the associated security-group rule. Deleting either app also removes managed private routes that reference it.

1. 01
   Create with a new app or attach later

   In New app, enable managed PostgreSQL to create the app and database as one coordinated workflow. For an existing running app, open Managed PostgreSQL and choose Create database. The system waits until app networking is available before it creates RDS.

2. 02
   Wait for database availability

   RDS provisioning can take several minutes. The database status progresses through creation and environment delivery. Do not add a hand-written DATABASE_URL while a managed attachment is being delivered.

3. 03
   Verify attachment

   Confirm database status available with the reason DATABASE_URL has been delivered to the app environment. Then confirm the app has deployed or restarted and use application logs to verify it connected successfully.

4. 04
   Rotate credentials

   Select Rotate credentials. Astroscale resets the RDS master password, updates the encrypted managed database credential, regenerates DATABASE_URL, waits for RDS to apply the change, delivers the new value, and restarts the attached application.

5. 05
   Delete a database

   Detach and delete it from Managed PostgreSQL only after the application no longer needs it. Verify the database's deletion state in the console and AWS RDS console. Deleting an app also starts the managed database cleanup path.