Changelog

We’re happy to announce that RabbitMQ 3.13 and 4.0 databases are now available on Aptible. If you’re interested in upgrading an existing RabbitMQ database, please reach out to Aptible Support for help.

We are excited to announce that SCIM (System for Cross-domain Identity Management) is now available on the Production and Enterprise plans.

SCIM facilitates automated user provisioning and deprovisioning and extends to group provisioning and linking to existing groups, significantly reducing the manual effort involved in user and group management while minimizing potential security risks. This enhancement equips our customers with robust user and group management capabilities, enhancing security and streamlining operations throughout their teams.

To start using this feature, see our SCIM Implementation Guide.

Container right-sizing recommendations are now shown in the Aptible Dashboard for App Services and Databases.
For each resource, one of the following scaling recommendations will show:

• Rightsized, indicating optimal performance and cost efficiency

• Scale Up, recommending increased resources to meet growing demand

• Scale Down, recommending a reduction to avoid overspending

Recommendations are updated daily based on the last two weeks of data, and provide vertical scaling recommendations for optimal container size and profile. Use the auto-fill button to apply recommended changes with a single click!

To begin using this feature, navigate to the App Services or Database page in the Aptible Dashboard.

TLSv1.3 is now available for HTTPS and Legacy ELB Endpoints, bringing additional security to your Apps. You can enable TLSv1.3 by configuring SSL_PROTOCOLS_OVERRIDE according to our documentation.

We are happy to announce that PostgreSQL 17 is now available on Aptible. PostgreSQL 17 introduces several updates, such as new JSON-related features and performance improvements across multiple key processes like vacuum and WAL processing. You can learn more in PostgreSQL’s official release post.

As of earlier this month, we began migrating customers to our new billing system, introducing several enhancements designed to improve visibility and simplify tracking costs.

1. Accumulated Usage: You can now see your usage as it accumulates throughout the month. The Draft Invoice displays your usage so far, and you can drill down further to view detailed usage by day and line item.

   

2. Projected Monthly Costs: We’ve relocated projected invoice information to the Stack and Environment pages, where it’s now labeled as “Estimated Monthly Costs.” This change aims to provide more contextual insight where it matters most.

3. Invoice History: The Invoice History page will show your current and future invoices on the new billing system. For access to historical invoices, simply click the link at the top of the billing portal.

   

4. PDF Invoice Downloads: You can now download invoices directly to PDF from the UI, making it easier to share and archive your billing records.

   

5. Improved Speed: Invoices now load significantly faster!

For more details, visit the billing dashboard or reach out to our support team if you have any questions.

We’re excited to announce that we’ve streamlined our plans to better meet the needs of organizations at different stages of growth. Our plans have been simplified from Starter, Growth, Scale, and Enterprise to just three tiers: Development, Production, and Enterprise.

One key difference with these new plans is that we've removed scaling limits. Initially, we introduced limits to help customers keep costs under control as they grew. However, we’ve learned that these restrictions were often more of a hindrance than a help. In response, we’ve eliminated these limits, allowing you to scale without boundaries. Instead, we’ve focused on giving you greater visibility into costs so you can manage your infrastructure spending effectively as you grow.

If you’re currently on the Starter, Growth, or Scale plans—your plan will remain as is, and no action is required. However, if you'd like to explore the new Development or Production plans, you can upgrade at any time. For more details and to review specifics, visit our pricing page.

Vertical Autoscaling is now generally available on the Enterprise plan!

Keep your apps right-sized effortlessly with Vertical Autoscaling, which automatically adjusts container profiles based on real-time CPU and RAM usage. Learn more in our docs.

You can now add gRPC endpoints to your gRPC apps, which enable zero-downtime deploys.

For more information please check the documentation

You can now force a zero-downtime deployment strategy for services without endpoints that leverages either a simple uptime healthcheck or Docker's healtcheck mechanism to ensure your services stay up during deployments.

For more information please check the documentation

We’re happy to announce that InfluxDB 2.7 is now available on Aptible. InfluxDB 2.X introduces many new tools to visualize and process your data alongside Flux, InfluxData’s data scripting language. You can read about these changes and more in InfluxDB’s release blog post. If you are interested in upgrading an existing InfluxDB database, please contact the Aptible support team for assistance.

Additionally, for those who prefer SQL-like queries over Flux, we have no plans to deprecate InfluxDB 1.8 at this time. We intend to continue making the older version available as a part of our managed database offering until InfluxDB 3.0 OSS is released or any security concerns arise.

Estimated monthly costs are now shown for environments and stacks in the Aptible Dashboard! The estimates reflect the cost of running the current resources for one month. It is updated automatically as resources are added or scaled to reflect the new estimated monthly cost. Please note: it does not represent your actual usage for the month (ongoing scaling operations or deprovisioned resources are not reflected).

As an expansion to before_release, add the following hooks within your .aptible.yml to set up better automation around app lifecycle events on Aptible:

• before_deploy (renamed from before_release. before_release is now deprecated, but will continue to work)

• after_deploy_success

• after_restart_success

• after_configure_success

• after_scale_success

• after_deploy_failure

• after_restart_failure

• after_configure_failure

• after_scale_failure

Check the docs for more information

We released a set of changes to our clients (UI, CLI, and Terraform) to make it easier for users to provision Apps and Databases with the desired scaling options. Previously, this had to be accomplished in two steps. For example, previously in the CLI, if a user was creating a PostgreSQL Database using our RAM Optimized container profile and 4000 IOPS, they would have to:

• Create the database aptible db:create (which defaults to our General Purpose container profile and 3000 IOPS)

• Then use the web UI to immediately scale the resource

As you can read, this is a disjointed user experience and we are happy to announce that we have feature parity across all of our clients.

Aptible CLI

• Users can now provide scaling options (container profile, container count, container size, disk size, or IOPS) upon creation of an App or Database via the CLI.

• Now all of these options can be provided in a single command:

  • aptible db:create --container-profile r --container-size 1024 --iops 4000

• The same changes also apply to:

  • aptible db:replicate

  • aptible backup:restore

• The same changes also apply to deploying an App for the first time:

  • aptible deploy --container-profile r --container-size 1024 --container-count 2

• Users can now provide --container-profile to aptible apps:scale and aptible db:restart

New version of CLI available here for download.

Aptible Terraform

• Users can now provide disk IOPS for Database and Replica resources

• We improved the performance of scaling an App resource

Aptible UI

• When creating a Database resource, users can now provide scaling options (container profile, disk size, container size, container profile, and IOPS)

As of 07/25/2024, all new Environments will have a default backup retention policy of:

• 30 daily backups

• 12 monthly backups

• 6 yearly backups

• Cross-region copies disabled

• Keep final backups enabled

This configuration still maintains 6 years of backups, as the previous default did, but reduces the overall number of backups retained over that period by over 6x, saving a significant amount on backup costs within a few months of databases coming online.

We've also added the backup recommendations in-app to make it easier to optimize existing environments.

Backup Retention Policies can now be managed via Terraform.

The backup_retention_policy block can be used to minimize cost or extend retention for Terraform-managed environments. Additionally, keep_final backups can also be disabled via Terraform; this allows forterraform destroy environments to work more efficiently as you no longer have to manually clean up final backups within the CLI or UI.

Database versions without active developer or community support will now be marked as (EOL) in the Dashboard. Additionally, after a 90-day period, EOL databases will be marked as (DEPRECATED) and will no longer be provisionable through the UI or CLI.

Following this policy, you will be unable to provision the following databases on October 31, 2024:

• Redis 6.0 and below

• PostgreSQL 11 and below

• MySQL 5.7 and below

• Elasticsearch 7.9 and below

• MongoDB 3.6 and below

• RabbitMQ 3.9 and below

• CouchDB

Notably, MongoDB 4.0 and Elasticsearch 7.10 will continue to be offered indefinitely, and CouchDB will no longer be available for new provisions on October 31st.

While this will not affect the functionality of any currently deployed databases, we encourage folks using EOL databases to upgrade to take advantage of new features and security measures introduced in later releases. We’ve included a short FAQ below, but if you have any questions regarding this new policy, please reach out to the support team.

FAQ:

Q: Will this affect my ability to backup, restore, or replicate databases on EOL or deprecated versions?
A: No, you will still be able to interact with existing databases in the same manner as before. However, new product features or improvements may not be compatible.

Q: I urgently need to provision a specific database version that is no longer available on Aptible. Can I have an exception?
A: Please get in touch Aptible Support with your specific request, and we’ll work with you to find an alternative solution.

Q: How can I identify my databases running on end-of-life versions?
A: You can search for "EOL" in the dashboard to filter for databases running on end-of-life versions.

Operation Blocking Improvements

Our users have given us feedback that certain operations blocking each other can really slow them down at critical moments. Based on that feedback, we've implemented improvements to operations which allow you to work more effectively. Specifically, this includes:

• Deploy/scale operations no longer block SSH sessions: Users can now SSH into an app while a deployment or scaling operation is ongoing. This change helps for quick debugging.

• Database backups no longer block database operations: Database operations, such as scaling, will no longer be blocked by automatic backups. This change helps for more efficient database management.

• Services within a given app can be scaled simultaneously: You can now scale multiple services within a given app at the same time, without waiting for each to complete. This update enables more effective and flexible service scaling.

New 'Last Deploy Banner' in SSH Sessions

With the new ability to SSH into an app during a deployment, we have updated our welcome banner for SSH sessions. The new banner displays:

• The date and time of the last completed deploy operation

• The source and reference for the deployed code

  
  

We made some changes to the user experience for Role Management. Functionally, roles and permissions have not changed, just the way users interact with roles has been updated:

• Users can now more easily view permissions within an Environment, App, and Database. Within a detail page, click the “Settings” tab and you will be able to see all the permissions associated with that entity.

• In the role management page, users can now filter by Role, User, and Environment.

• We have condensed the role management view to make it easier to navigate and find exactly what you are looking for.

• We also now provide an export to CSV button that will print the roles, members, environments, and permissions currently filtered.

• We have also condensed the permission editor and streamlined making changes in an effort to make it easier to manage permissions.

Aptible will now display a container recovery initiated message when a container has restarted due to an event outside of its normal lifecycle. This change helps better differentiate between container restarts due to application deployment and a container recovery event.

Over the next several weeks, the Aptible team will be migrating VPN Tunnels to new appliances to ensure continued and reliable service. During this time, our team will be reaching out to coordinate the migration.

Once the migration is complete, additional VPN Tunnel details will now be available in the UI. More specifically, VPN Status will now be shown for more effective monitoring/troubleshooting.

Read more about managing VPNs and their status here in our docs.

If you'd like to schedule a migration to the new appliance ahead of time, please contact our support team!

New commands for managing backup retention policies via the CLI

Environment Backup Retention Policies can now be managed via the Aptible CLI. Use aptible backup_retention_policy to get the current policy for an Environment and aptible backup_retention_policy:set to change the policy.

Improvements to config:get command

aptible config:get can now be used to get a single value from an App's Configuration.

CLI installation instructions

Previously, the "Dependencies" tab when viewing an App's details on app.aptible.com would only show Aptible Databases that could be detected from the App's configuration (environment variables). Now, it can detect dependencies on other Aptible Apps by comparing domain names detected in the App's configuration with the domains associated with Endpoints. While this method of dependency detection cannot find every dependency an App has, we believe it is a positive step toward making everyone's Aptible architecture easily discoverable.

We have introduced a new “Sources” page—designed to track what code is deployed where by linking your apps to their source repositories.

This integration allows for a comprehensive view of deployed code across your infrastructure. You can navigate the Sources page to identify groups of apps sharing the same code source and drill into the Source Details for insights into current and historical changes of code deployed.

See our docs for more information on Sources!

To enhance our platform security, Aptible is enforcing a minimum TLS version of TLSv1.2 for all Aptible APIs and sites starting 5/1/2024. Support for TLSv1.0 and TLSv1.1 will be discontinued at this date.

This affects Aptible’s own APIs and sites, including:

• aptible.com

• app.aptible.com

• dashboard.aptible.com

• Maintenance Pages (Brickwall)

Your App Endpoints and Database Endpoints are unaffected by this change.

All modern browsers and operating systems natively support TLSv1.2 already, however if your client is using TLSv1.0 or TLSv1.1, then you must update your client to use TLSv1.2 to continue using Aptible APIs and sites listed above.

For more information on TLSv1.2 compatibility, see this documentation.

We are happy to announce that Aptible now supports provisioning RabbitMQ 3.12 databases.

We’ve released a minor version update for MySQL: 8.0.33. This will automatically apply upon the next restart or reload of your MySQL databases.

Configuration Changes

Below are the listed changes that you should be aware of as they are a change in behavior for the current configuration of MySQL.

• The SSL Cipher is changing from DHE-RSA-AES256-SHA256 to the new default of TLS_AES_256_GCM_SHA384

• TLS 1.0 and 1.1 are no longer supported as of this version. Only TLS 1.2 and 1.3 are available.

If you have any questions or concerns, please contact our Support Team.

Yearly Backups

Aptible now supports Yearly automatic backups.

For new and existing environments, the retention policy will be set to 0. We highly recommend reducing the frequency of daily and monthly automatic backups when implementing yearly backups as a cost-optimization measure.

See our docs for more information on automatic yearly backups

Exclude DB from Backups Setting

We've introduced a per-database setting which allows for the ability to exclude that database from new automatic backups. Please note: this does not automatically purge previously taken backups.

See our docs for more information on: how to exclude a database from future backups and how to purge the previously taken backups for a given database.

Aptible is releasing PostgreSQL versions 15 and 16 as a part of our managed database service offering.

Please make note of the following significant changes related to this release:

• Aptible will not offer in-place upgrades to PostgreSQL 15 and 16 because of a dependent change in glibc on the underlying Debian operation system. Instead, the following options are available to migrate existing pre-15 PostgreSQL databases to PostgreSQL 15+.

  • Dump and restore PostgreSQL

  • Upgrade PostgreSQL with logical replication

• contrib images are being consolidated. Previously, we have maintained two separate PostgreSQL images: a contrib image that included commonly requested extensions and a standard image with only a few critical extensions like pglogical. Starting with PostgreSQL 15, we will no longer maintain a separate image. Instead, we will be bundling extensions into our standard PostgreSQL image. If there is an extension you’d like to see added, please reach out to the team through our support portal.

The Aptible team has performed maintenance on all customer accounts, which has allowed us to implement the following platform improvements:

• Next generation of EC2 hardware: We’ve migrated “General Purpose” containers to the next generation of EC2 hardware for overall better performance

• Implemented CPU Shares and deprecated CPU Isolation (formerly CPU limits): Up until now, customers with CPU Isolation: Disabled have been able to take advantage of additional CPU resources beyond their allocated limit due to traditional CPU Limits not being enabled and the occasional scheduling of containers on larger infrastructure hosts, which allowed for additional CPU usage. We are transitioning to a CPU-share model with right-sized host matching to improve system efficiency and predictable performance. To provide a practical example, a given app could be running a single 4GB container on a 16GB infrastructure host by itself due to several contributing factors. This container would be allocated a single full CPU but could exceed that by up to 4x (400% CPU utilization). With this new model, this container will be rescheduled on a host closer in size to the container. When the container overruns its single full CPU allocation and reaches the limits of the host’s CPU capacity, it would be throttled to ensure the stability of the host and, by extension, the service. This necessary change lays the groundwork for some exciting upcoming changes, including autoscaling.

• Maintenance Commands: We have added two new Aptible CLI commands to simplify further the process of ensuring the required App and Database restarts are complete: aptible maintenance:apps and aptible maintenance:dbs. These commands list Apps and Databases that are required to be restarted to complete any outstanding maintenance and allow customers to track which resources will be restarted by Aptible's SRE time at the indicated maintenance window. Please upgrade your Aptible CLI now to version 0.19.7 or newer to use these commands.

• Improved API Performance

Account Owners can now reset a user's 2FA in the Members page under Settings. Account Owners can reset 2FA for all other users, including other Account Owners, but cannot reset their own 2FA. Once the Account Owner kicks off the reset, the selected user will receive an email with a link asking that they confirm and complete the 2FA reset.

We're excited to share further improvements to the new Aptible Dashboard, which is currently in Beta. The latest additions:

• A new Endpoints page to view and manage all Endpoints within an organization

• A new support request form directly via the Dashboard — built with smart suggestions

• Apps and Databases can now be restarted via the Dashboard

• Databases can be migrated to a new region with the Restart Database with Disk Backup and Restore settings

• InfluxDB 2 Metric Drains are now supported via the new Dashboard

• Environment Variables are now viewable and configurable via the Dashboard

• Bug fixes

Read the full blog here from our Staff Product Designer

We’re excited to announce a preview of our new Aptible Dashboard, which is currently in Beta. With this new Dashboard, we aim to improve our platform's navigation, speed, and usability — focusing on the overall developer experience.

We’re just getting started, but to kick things off, you can try the new Dashboard here with the following features:

• An entirely fresh new look to the Dashboard

• A new navigation with per-resource pages to hone in on the resources you are looking for, including dedicated pages for Stacks, Environments, Apps, and Databases

• A new Activity page to easily view and manage operations, including operation logs

• A new Deployments page to manage deployments triggered via the Dashboard

• Omni-search for resources across the entire organization

• In-app metrics now persist after deploys and restarts

• In-app metrics now show a 1-week look back (in addition to hourly and daily) with more granularity than ever before

Try the new Aptible Dashboard here!

Aptible now supports Redis 6.2. To upgrade your Redis database, please see our guide for “How to upgrade Redis”

Aptible will now include a “CPU Limit” metric in the metrics delivered through metric drains so users can understand app and database container performance better.

In the past, Aptible only offered the General Purpose container profile. Since this was standard across all containers, users could easily calculate the CPU limit based on the fixed CPU-to-RAM ratio. The release of RAM and CPU-Optimized container profiles, each with unique CPU-to-RAM ratios, introduced a new need for a CPU Limit metric.

You can compare the existing CPU Usage metric with the new CPU Limit metric to monitor when your app or database containers are nearing their CPU limit, and scale accordingly. However, if CPU Isolation is disabled, the container will have no CPU limit, and the CPU Limit metric will return 0. If you have not enabled CPU Isolation, we highly recommend doing so, as you may experience unpredictable performance in its absence. If CPU Isolation is enabled, the metric returns the allocated CPU per millisecond. For example, a CPU limit of 1 in the dashboard will be reflected as 1000 by the metric, or a CPU limit of .5 in the dashboard will be reflected as 500 by the metric. Please contact Aptible Support if you have any questions before the release.

Please note: as part of this change set, it became necessary to change the host tag to host_name for referencing the Container Hostname (Short Container ID).. Any pre-built queries on customer metrics platforms which rely on the host tag may need to be changed to reference host_name instead.

Operations completed by the Aptible Reliability Team will now include a note indicating reason the operation (for example: maintenance restarts).

The maximum amount of IP sources (aka IPv4 addresses and CIDRs) per Endpoint available for IP filtering has been increased from 25 to 50. If you've created multiple Endpoints as a workaround in the past, you may want to consider consolidating back to one Endpoint.

This year, we announced that we are refocusing our efforts with the goal of delivering ✨magical experiences✨for developers. To deliver on that mission, we created an entirely new experience within the Aptible Dashboard, which allows users to easily deploy code to a new environment with the necessary resources. Whether you're just starting out on Aptible or a seasoned power user, we want to continue to enable you to have a seamless deployment process.

Without further ado, we are happy to introduce you to the new Deploy Code button with the Aptible Dashboard.

The Deploy Code process will guide you through the following steps:

1. Setup an SSH Key: Authenticate with Aptible by setting up your SSH key (if you haven't done so already)

2. Create a new environment: Set up a new environment where your resources will reside

3. Select app type: Choose the type of app you want to deploy, whether it's from our starter templates, the Aptible demo app, or your own custom code

4. Push your code: Deploy your code to Aptible using a git push

5. Create databases (optional): Create and configure managed database(s) for your app

6. Set and configure environment variables (optional): Customize your app by setting and configuring variables

7. Set Services and Commands (optional): Fine-tune your app's services and commands

8. View Logs: Track the progress of your resources as they deploy, and if something goes wrong, you edit your configuration and then rerun the deployment – all within the Dashboard

And voilà - your code is deployed! ✨

But don’t take our word for it - give it a try here, and if you have ideas or feedback - let us know! We are actively iterating on this flow, so we’d love to hear from you about what you’d like to see next.

We are excited to announce Granular Permissions for fine-tuning user access on the Environment level! Formerly, Aptible had a simple read/write permission scheme, but as part of this release, we've introduced 2 new read permissions and 6 new write permissions, which can be assigned using Custom Roles. Read the docs here or read our blog post.

Modifying a Custom Role

Deleting Custom Roles Custom Roles can now be deleted within the Aptible Dashboard. You can do this by navigating to the Custom Role you would like to delete, then navigating to the Settings tab.

Deleting a Custom Role

We are excited to announce we've updated our site-to-site VPN tunnel implementation. This update comes with support for IKEv2 VPN tunnels for greater reliability and security, as well as improved compatibility with Azure-based connections.

Learn more about setting up VPN tunnels here.

To request an existing VPN tunnel be migrated to IKEv2, contact Aptible Support.

For improved compatibility and security, we've added ED25519 to the supported SSH key algorithms we accept. You can now generate ED25519 SSH keys. You can manage your keys here within the Aptible Dashboard.

aptible_environment resources can now be managed through Terraform. Learn more here about resource attributes and configuration.

Modify Container Profiles via Terraform container_profile can now be modified for App services and Databases through Terraform. This can be used to select a workload-appropriate Container Profile for a given service: General Purpose, CPU Optimized, or RAM Optimized. Learn more here about resource attributes and configuration.

Look up Stacks via Terraform aptible_stack data sources are now available through Terraform. This can be used to look up Stacks by name. Learn more here about resource attributes.

aptible_metric_drain resources can now be managed through Terraform. Learn more here about resource attributes and configuration.

Pre-built Grafana dashboards and alerting You can now use the aptible/metrics Terraform module to provision Metric Drains with pre-built Grafana dashboards and alerts for monitoring RAM & CPU usage for your Apps & Databases. This simplifies the setup of Metric Drains so you can start monitoring your Aptible resources immediately, all hosted within your Aptible account!

App metrics in the pre-built Grafana dashboard

Database metrics in the pre-built Grafana dashboard

Alert rules in the pre-built Grafana dashboard

With our new S3 Log Archiving functionality, you can now configure log archiving to an Amazon S3 bucket owned by you! This feature is designed to be an important complement to Log Drains, so you can retain logs for compliance in the event your primary logging provider experiences delivery or availability issues.

By sending these files to an S3 bucket owned by you, you have the flexibility to set retention policies as needed - with the security of knowing your data is encrypted in transit and at rest. Decryption is handled automatically upon retrieval via the Aptible CLI.

Learn more about setting up S3 Log Archiving. When you're ready to finalize the setup, contact Aptible Support and provide the following information:

• Your AWS Account ID

• The name of your S3 bucket to use for archiving

You can now manage aptible_log_drain resources through our Terraform Provider. Learn more here about resource attributes and configuration.

Terraform Endpoint Bug Fix Feedback suggested by the Terraform Provider claimed that Endpoint placement could change (e.g. external to internal) but it cannot without a destructive operation (e.g. destroy and recreate).ForceNew now occurs on Endpoint placement changes in the Aptible Terraform Provider. This will result in an Endpoint being destroyed and then recreated.

We've updated the Aptible Dashboard, so all supported Disk and Container sizes are available for scaling. Previously, the Aptible CLI supported more scaling sizes than the Aptible Dashboard.

New Renaming Commands You can now rename apps, databases, and environments via the Aptible CLI using these new commands:

• aptible environment:rename Learn more

• aptible app:rename Learn more

• aptible database:rename Learn more

Previously, this could only be done by the Aptible Support team.

Improved Terraform Error Messages The Aptible Terraform provider will now return more informative error messages from the server (for example, validation errors or other informative errors the Aptible backend may return) with a status code and message. Previously, errors were unclear by pointers returned by the client, making it impossible to read the backend errors themselves with no status code or message.

Prior to today, operation logs could only be accessed in real-time via the Aptible CLI, while an operation was running. This made debugging difficult in a number of scenarios:

• Terraform operations, for which logs are not captured

• CI-initiated jobs disconnected due to a CI service issue

• Manual operations inadvertently disconnected via Ctrl-C

• Manual operations initiated from the Aptible Dashboard

Today, we have released support for downloading logs for completed operations from the Aptible Dashboard or CLI, and also for attaching to real-time logs via Aptible CLI by providing the operation ID.

When you navigate to an App or Database in the Aptible Dashboard and view the Activity tab for that resource, you'll see a log download icon to the right of the timestamp:

Using the Aptible CLI, you can follow the logs of a running operation:

aptible operation:follow OPERATION_ID

...and view the logs for a completed operation:

aptible operation:logs OPERATION_ID

These can be set with APTIBLE_USERNAME and APTIBLE_PASSWORD environment variables. Learn more here.

Rename App and Database handles To change a handle for an existing resource, simply change the string passed into the handle field for a given Database or App and the change will reflect within Aptible (both UI and CLI). The affected fields are the app handle and database handle.

We are excited to share Aptible's underlying container scheduler has been radically improved. New EC2 instances provisioned during releases and scaling operations are now quicker and more reliable. Operations that previously took 15+ minutes to launch new EC2 instances will now take less than 3 minutes for the same process (x5 times faster)!

We are excited to announce that Container Profiles and Enforced Resource Allocation are now generally available on Aptible. By default, new Dedicated Stacks and all Shared Stacks have Enforced Resource Allocation enabled—meaning CPU Limits and Memory Limits are enabled and enforced for each container.

The new Container Profiles can be found under the Scale menu of your Aptible dashboard, for stacks with Enforced Resource Allocation enabled.

These improvements include new Container Profiles with different CPU to RAM ratios and a range of supported Container sizes, helping you to optimize your costs for different applications. The three types of Container Profiles currently available are as follows:

• General Purpose: The default Container Profile, which works well for most use cases.

• CPU Optimized: For CPU-constrained workloads, this profile provides high-performance CPUs and more CPU per GB of RAM.

• Memory Optimized: For memory-constrained workloads, this profile provides more RAM for each CPU allocated to the container.

Aptible strongly recommends enabling Enforced Resource Allocation on existing Dedicated Stacks which don't currently enforce CPU Limits. Check out our FAQ on CPU Limits for more information about Enforced Resource Allocation!

We have released support for additional Redis and Postgres versions. Aptible Deploy is now compatible with Redis 6 and 7 and Postgres 9.6.24, 10.21, 11.16, 12.11, 13.7, and 14.4.

Improved Deploy Times We have fixed a bug that was causing builds to miss the cache more frequently than they should, thereby increasing deploy times. A new release should make it more likely that builds will hit the cache.

If the build continues to be a pain point, we recommend switching to Direct Docker Image Deployment to gain full control over the build process.

We are thrilled to announce that Single Sign-On (SSO) is now available on all Aptible infrastructure at no additional cost. Formerly, this was only available to Enterprise customers.

With SSO, you can allow users of your organization to log in to Aptible using a SAML-based identity provider like Okta and GSuite.

Learn more about setting up SSO for your organization.

We've added small improvements to the end user experience when setting up Log Drains, and when scaling Services.

Scaling Services

Clicking Scale in a Service now shows a "drawer" with options shown to horizontally or vertically scale your services. The Metrics tab in the drawer allows you to quickly navigate to Container Service metrics to make better informed scaling decisions.

Outside of the drawer experience, the key change is the ability to vertically scale your services to every possible size right up to the instance's maximum allowed limit in the UI. Previously, scaling beyond 7 GB this was only possible through the CLI. In addition, we've made it possible for you to see the CPU share per container based on the enforcements of CPU limits for better predictability in performance.

Setting up Log Drains

While the experience to set up Log Drains is still the same, minor improvements where made to the overall visual design.

Docker images are an essential component for building containers because they serve as the base of a container. Dockerfiles – lists of instructions that are automatically executed - are written to create specific Docker images. Avoiding large images speeds up the build and deployment of containers, thus contributing positively to your DevOps performance metrics.

Keeping image sizes low can prove challenging. Each instruction in the Dockerfile adds one additional layer to the image, contributing to the size of the image. Shell tricks had to be otherwise employed to write a clean, efficient Dockerfile and to ensure that each layer has the artifacts it needs from the previous layer and nothing else, all of which takes effort and creativity, in addition to being error prone. It was also not uncommon to have separate Dockerfiles for development and a slimmed down version for production, commonly referred to as the "builder pattern". Maintaining multiple Dockerfiles for the same project is not ideal as it could produce different results between development and production, making software development, testing and bug fixes unreliable when pushing new code.

Docker introduced multi-stage builds to solve for the above, which Aptible now supports when using Dockerfile Deploys. Please note that users deploying using the Direct Docker Image Deployment method on Aptible could have used multi-stage builds prior to this release.

Using multi-stage builds

With multi-stage builds, you use multiple FROM statements in your Dockerfile. Each FROM instruction can use a different base, and each of them begins a new stage of the build. You can selectively copy artifacts from one stage to another, leaving behind everything you don’t want in the final image.

You can learn more about how to use the FROM instructional statements, naming different build stages in your Dockerfile, picking up from when a previous stage was left off, and more here.

Over the years, the Aptible product teams have learned that a vast number of teams would benefit from not just having greater visibility into the security safeguards Aptible has in place across different aspects of the infrastructure, but also get insights to understand what they need to do to further improve their posture to reach a compliance goal.

To help with this, we’re excited to be announcing the newest Aptible feature - the Compliance Visibility Dashboard!

The Compliance Visibility Dashboard provides a unified view of all the technical security controls in place that Aptible fully enforces and manages on your behalf, as well as security configurations you have controls over in the platform.

Think of security controls as safeguards implemented to protect various forms of data and infrastructure, important both for compliance satisfaction as well as best-practice security.

Video explaining how the Dashboard works.

With this feature, you can not only see in detail the many infrastructure security controls Aptible automatically enforces on you behalf, but also get actionable recommendations around safeguards you can configure on the platform (for example, enabling cross-region backup creation) to improve you overall security posture and accelerate compliance with frameworks like HIPAA and HITRUST. Apart from being visualized in the main Aptible Dashboard, these controls along with their descriptions can be exported as a print-friendly PDF for sharing externally with prospects and auditors to gain their trust and confidence faster.

You can access the Compliance Visibility Dashboard by clicking on the Security & Compliance tab in the navigation bar.

Here’s documentation to learn more about using the Dashboard in greater detail.

Broadly speaking, two levels of access can be granted to Users through Aptible Roles on a per-Environments basis

• Manage Access: Provides Users with full read and write permissions on all resources in a particular Environment.

• Read Access: Provides Users with read-only access to all resources in an Environment, including App configuration and Database credentials.

While Users with read access are not allowed to make any changes, or create Ephemeral SSH Sessions or Database Tunnels, they were still able to view credentials of their Aptible-managed Databases. This was possible either through the Database dashboard or through the CLI with the [aptible db:url] and the APTIBLE_OUTPUT_FORMAT=json aptible db:list commands.

For heightened security, Users with read access can no longer see Database Credentials, both in the UI or through the CLI.