We are excited to announce the general availability of persistent storage support for OCI Container Instances (CI) through File Storage Service (FSS). With this release, customers can mount persistent volumes backed by OCI File Storage Service directly into containers running on container instances, enabling applications to retain, share, and manage data independent of the container instance lifecycle. Applications can continue across container restarts, replacements, and new runs, making it easier for customers to run stateful workloads on CI while preserving the simplicity of serverless containers.

With this release, CI expands beyond simple stateless tasks to support sophisticated stateful applications that require durable shared storage. As customer usage patterns have broadened, many teams have asked to bring that same experience to workloads that need durable state. These workloads may need to preserve generated files, share datasets across runs, or resume work after a container instance is stopped and recreated. For these workloads, the first storage need is often simple but critical: retain and share files.

FSS is a natural first persistent storage option because it gives customers a familiar file system interface and POSIX semantics. Applications can retain and share files without adopting a new storage API or redesigning around a different persistence model. With OCI File Storage Service, customers get this simplicity through a durable, shared, enterprise-grade network file system.

FSS support expands what customers can build with CI. Teams can bring existing stateful applications, scripts, frameworks, and operational practices to Container Instances, moving beyond temporary tasks to ongoing services and workflows. This unlocks a broader set of use cases such as content and file-based applications, iterative AI workflows, CI/CD pipelines, and data-processing jobs that need durable shared storage while preserving the simplicity of serverless containers.

The feature is also designed for enterprise deployment patterns. Customers can mount FSS resources to a container instance in the same tenancy or across-tenancies in the same region, which is especially useful when compute is centrally provisioned, but data is owned or managed by a different team. Customers can also use capabilities such as subdirectory mounts, read-only mounts, and encryption in transit, helping them to manage access, security, and data ownership.

This capability is available everywhere CI and FSS are available. There is no additional charge to use this feature beyond the compute and storage resources used.

Simple Walkthrough

Pre-requisite

Before you create a container instance that mounts FSS storage, create or identify the required OCI File Storage resources. These include the file system, the mount target that exposes the file system, and the export that the CI will mount.

You will also need to configure the required IAM policies and network access so the container instance can reach and use the referenced File Storage resources. This includes standard Container Instances permissions, FSS permissions for the referenced resources, and any additional cross-tenancy policies if the container instance, subnet, or FSS resources are managed in different tenancies.

For complete setup instructions, including IAM policy examples, network security rules, cross-tenancy configuration, and full API details, see the CI FSS support technical documentation.

FSS Mount

The following simplified JSON example shows a container Instance configuration that mounts an FSS backed volume into a container at /mnt/fss. The FSS volume is referenced by mount target OCID and export OCID, and the container mounts a subdirectory named team-a.

{
  "displayName": "ci-fss-demo",
  "compartmentId": "ocid1.compartment.oc1..exampleuniqueID",
  "availabilityDomain": "Uocm:PHX-AD-1",
  "shape": "CI.Standard.E4.Flex",
  "shapeConfig": {
    "ocpus": 1,
    "memoryInGBs": 2
  },
  "securityContext": {
    "securityContextType": "LINUX",
    "fsGroup": 1000,
    "fsGroupChangePolicy": "ON_ROOT_MISMATCH"
  },
  "volumes": [
    {
      "name": "shared-fss",
      "volumeType": "OCI_FSS_FILE_SYSTEM",
      "mountTarget": {
        "ociFssMountTargetType": "OCID",
        "id": "ocid1.mounttarget.oc1.phx.exampleuniqueID"
      },
      "export": {
        "ociFssExportType": "OCID",
        "id": "ocid1.export.oc1.phx.exampleuniqueID"
      },
      "security": {
        "auth": "SYS",
        "isEncryptedInTransit": true
      },
      "mountCommand": {
        "mountOptions": [
          { "option": "hard" },
          { "option": "noac" },
          { "option": "retrans", "value": "11" }
        ]
      },
      "subnetId": "ocid1.subnet.oc1.phx.fsspathuniqueID"
    }
  ],
  "containers": [
    {
      "displayName": "app",
      "imageUrl": "docker.io/library/busybox:latest",
      "command": ["/bin/sh", "-c"],
      "arguments": ["sleep 3600"],
      "volumeMounts": [
        {
          "volumeName": "shared-fss",
          "mountPath": "/mnt/fss",
          "subPath": "team-a",
          "isReadOnly": false
        }
      ]
    }
  ],
  "vnics": [
    {
      "subnetId": "ocid1.subnet.oc1.phx.primaryuniqueID",
      "purpose": "PRIMARY"
    }
  ]
}

Build stateful applications with the simplicity of CI

Persistent FSS support expands what customers can build with OCI Container Instances. Teams can now run stateful workloads that need durable, shared file storage while continuing to use CI’s simple, elastic, serverless operating model. Whether you are storing application content, sharing datasets, preserving build artifacts, or checkpointing AI workflows, persistent FSS volumes make it easier to keep state outside the container lifecycle and focus on building the application.

Learn more