Deploy DAGs with NFS
You can use an external Network File System (NFS) Volume to deploy Dags to an Airflow Deployment on Astro Private Cloud (APC).
Unlike deploying Dags with the Astro CLI, deploying Dags to an NFS volume doesn’t require rebuilding a Docker image and restarting your underlying Airflow service. When a Dag is added to an NFS volume, it automatically appears in the Airflow UI without requiring additional action or causing downtime.
How NFS deploys work
When you configure an NFS volume for a Deployment:
- APC validates the NFS location format (
SERVER_IP:PATH). - APC creates a Kubernetes PersistentVolume (PV) pointing to your NFS server.
- APC creates a PersistentVolumeClaim (PVC) bound to the PV.
- The NFS volume is mounted read-only to the scheduler and workers at
/usr/local/airflow/dags. - Dags are synced by writing files directly to your NFS server.
Implementation considerations
If you configure NFS for a Deployment, you can’t use the Astro CLI or service accounts to deploy DAGs to that Deployment. NFS becomes the exclusive deployment mechanism.
Before configuring NFS deploys:
- Namespace pools limitation: NFS deploys will not work if you use namespace pools and set
global.clusterRolestofalse. The NFS deploy feature requires creating PersistentVolumes, which are cluster-scoped resources. - Dags only: NFS volumes deploy only Dags. To add Python dependencies or system packages, update your
requirements.txtandpackages.txtfiles and deploy using the CLI or CI/CD. - Airflow version: NFS volumes require Airflow 2.0 or later.
- Read-only mount: The NFS volume is mounted read-only to Airflow components. Write operations must happen directly on the NFS server.
Prerequisites
- APC 1.0 or later installed
- An NFS server accessible from your Kubernetes cluster
- Network connectivity between cluster nodes and the NFS server
- Read access configured for UID/GID
50000on the NFS share
Enable NFS volume storage
A System Admin must enable NFS deploys on the platform. Update your values.yaml:
Apply the configuration change:
Provision an NFS volume
AWS (EFS)
GCP (Filestore)
Azure (Azure Files)
Self-managed
- Create an EFS file system.
- Configure security groups to allow NFS traffic (port 2049) from your EKS nodes.
- Create an access point or use the root directory.
- Note the file system DNS name:
fs-xxxxxxxx.efs.region.amazonaws.com.
Configure NFS for a Deployment
UI
CLI
API
- In the APC UI, create a new Deployment or open an existing one.
- Go to DAG Deployment in the Deployment settings.
- Select NFS Volume Mount as the mechanism.
- Enter the NFS location in
IP:PATHformat:- AWS EFS:
10.0.0.1:/ - GCP Filestore:
10.0.0.1:/dags - Azure Files:
storage-account.file.core.windows.net:/storage-account/share-name
- AWS EFS:
- Click Save or Deploy Changes.
Deploy Dags to NFS volume
Once configured, deploy Dags by copying files to your NFS server. The method depends on your infrastructure:
Direct copy
Using kubectl
If you have a pod with NFS access:
CI/CD integration
Example GitHub Actions workflow:
Sync from cloud storage
For cloud-native workflows, sync from object storage:
Verify NFS configuration
Check that the PV and PVC were created:
Verify the volume is mounted in Airflow pods:
Troubleshooting
Dags aren’t appearing
-
Check NFS connectivity:
-
Verify mount permissions:
-
Check PV/PVC status:
Permission denied errors
Ensure your NFS export allows access for UID/GID 50000:
Stale file handle
If pods report stale NFS handles after server restart:
Network connectivity issues
Verify NFS port (2049) is accessible:
Security considerations
- Network isolation: Use network policies to restrict which pods can access the NFS server.
- Access control: Configure NFS exports to allow only Kubernetes node IPs.
- Read-only mounts: APC mounts NFS volumes read-only to prevent accidental modifications from Airflow.
- Audit logging: Enable NFS server audit logging for compliance requirements.
Alternative: Git-sync deploys
If NFS infrastructure isn’t available, consider git-sync deploys which pull DAGs from a Git repository. Git-sync provides:
- Version control for Dags.
- No external storage infrastructure required.
- Webhook-based or polling synchronization.
- Branch-based deployment strategies.