Guide for users without resources
Activate your account
Check your notification email for a link to the new Tenant Manager, or visit tenant-manager.code-de.org. For security reasons you must set a new password. You will also see an onboarding form — fill it out and verify all information is still current.
Check your organization
An “Organization” is an administrative unit in CODE-DE-Lab’s user and contract management. Log in to Tenant Manager and navigate to Configuration → Organization. If your account was part of an organization previously, that information was copied — double-check it is still correct.
Information about affiliation
In addition to your platform ‘Organization’, the ‘Affiliation’ field specifies your actual employer. These details are strictly required because certain data on CODE-DE-Lab are subject to export control restrictions. To perform the necessary legal compliance checks, providing this information is a mandatory requirement; without it, we are legally unable to grant access to the platform.
Note: Data Catalogue & Archive
Backend access for Sentinel and contributing missions now sources directly from CREODIAS. Coverage has expanded from Germany-only to the entire world.
If your scripts query data exclusively over Germany, you must explicitly configure an Area of Interest (AOI) spatial boundary in all search queries. Without this filter, responses return global results causing severely prolonged times and massive metadata payloads that could break automated workflows.
Guide for users with resources
Complete these steps right after migration to ensure your infrastructure is correctly set up.
Activate your account
Check your notification email for a link to the new Tenant Manager, or visit tenant-manager.code-de.org. Set a new password and complete the onboarding form.
Check your organization
Navigate to Configuration → Organization in Tenant Manager. Verify that the organization details copied from the previous platform are correct.
Information about affiliation
In addition to your platform ‘Organization’, the ‘Affiliation’ field specifies your actual employer. These details are strictly required because certain data on CODE-DE-Lab are subject to export control restrictions. To perform the necessary legal compliance checks, providing this information is a mandatory requirement; without it, we are legally unable to grant access to the platform.
Post-Migration OpenStack Account Activation
To complete your migration and successfully activate your Domain Admin role via the automated provisioner, you need to manually refresh your administrator status in the new environment. This action triggers Keystone to apply your elevated permissions.
Step-by-Step Instructions
- Log in as User-1.
- Navigate to the Sub-accounts tab in the main menu.
- Locate the account for User-2 and remove (toggle OFF) the Admin role.
- Wait for 10–15 seconds to allow the system to process the removal.
- Re-add the Admin role: toggle the Admin role for User-2 back ON (or add it again).
- Log out.
- Log in as User-2.
- Repeat steps 3–5 for all other admin users.
If you encounter any other issues while changing your permissions or logging in to the OpenStack GUI, please contact the support team.
Login to OpenStack Horizon Dashboard
Under Management Interfaces in Tenant Manager, find the link to FRA1-3 Horizon — the new cloud region management portal.
Generate a new RC file in OpenStack
Option A — via your username
- Log in to the Horizon Dashboard
- Top-right corner: click your username → OpenStack RC File (2FA)
Option B — via Project menu
- Go to Project → API Access
- Click “Download OpenStack RC File” (top-right)
- Choose RC File (2FA) for password auth or clouds.yaml for an alternative format
Floating IP addresses
Due to the Frankfurt data center relocation, a new IP address range is in use. New Floating IPs are automatically assigned to your VM instances during migration.
Action required: Update any workflows that reference your previous IP addresses with the new ones.
Check and re-activate your VM instances
In the Horizon Dashboard, navigate to the Instances section. Verify that all resources were copied as expected and are currently in the Active state.
Check your storage volumes (block storage)
Navigate to the Volumes section in OpenStack and verify all block storage volumes have been successfully migrated with their correct sizes and attachments. If any volumes were detached prior to migration, re-associate them before attempting to mount or resume services.
Check your object storage containers
Open the Object Storage dashboard and verify buckets, containers, and data objects transferred intact. Also verify:
- Access credentials are correctly configured
- Lifecycle policies are in place
- API container configurations match the new platform environment
Generate new EC2 credentials
To access buckets via the CLI, generate new EC2 credentials with the command below.
Check security groups
Navigate to Network → Security Groups and confirm all custom firewall rules have been correctly re-created. In the Instances overview, select each individual VM and verify the Security Group section shows the correct groups.
EO data mounting
Mountpoint settings differ slightly due to the new region. Run the following to ensure the data directory is mounted correctly:
Alternative: Mount EO data via s3cmd & s3fs
If neither of the above methods works, you can configure access to the EO data bucket manually using your personal S3 credentials from Tenant Manager (Configuration → S3 Credentials).
Step 1 — Install tools
Step 2 — Configure s3cmd
Run the interactive configurator and enter your credentials when prompted:
Use the following values when prompted:
- Access Key: your key from Tenant Manager
- Secret Key: your secret from Tenant Manager
- S3 Endpoint:
eodata.code-de.org - Encryption password: leave blank
- Use HTTPS: Yes
- Region / location constraint:
s3.fra1-3.cloudferro.com
Test the connection:
Step 3 — Mount with s3fs
Write your credentials to the s3fs password file:
Mount the bucket:
Verify:
Step 4 — Make the mount persistent via /etc/fstab
To automatically mount the bucket on every system boot, add the following line to /etc/fstab:
Test without rebooting:
The old mount points /eolab and /codede are no longer valid. Symbolic links have been added to redirect them to /eodata.
SSH key pairs
SSH key pairs will likely not be visible under Key Pairs in the new dashboard for migrated machines. However, the cryptographic keys remain securely injected within the VMs — SSH access should continue to function as before.
Remember: Use the new Floating IP addresses when connecting to your VMs.
New flavor mapping (FRA1-1 → FRA1-3)
The FRA1-3 region uses updated flavor names. Find your old flavor in the left column:
hma— AMD CPUshmad— AMD CPUs without local SSDhmaw— Windows instancesvgpu— A6000 GPU instances
| FRA1-1 (old) | FRA1-3 (new) |
|---|---|
| eo1.xsmall | eo1a.xsmall |
| eo1.small | eo1a.small |
| eo1.medium | eo1a.medium |
| eo1.xmedium | eo1a.xmedium |
| eo1.large | eo1a.large |
| eo2.medium | eo2a.medium |
| eo2.large | eo2a.large |
| eo2.xlarge | eo2a.xlarge |
| eo2.2xlarge | eo2a.2xlarge |
| hm.medium | hma.medium |
| hm.large | hma.large |
| hm.xlarge | hma.xlarge |
| hm.2xlarge | hma.2xlarge |
| vm.a6000.1 | vgpu.a6000.6gb |
| vm.a6000.2 | vgpu.a6000.12gb |
| vm.a6000.4 | vgpu.a6000.24gb |
| vm.a6000.8 | vgpu.a6000.48gb |
Note: Data Catalogue & Archive
Backend access for Sentinel and contributing missions now sources directly from CREODIAS. Coverage has expanded from Germany-only to the entire world.
If your scripts query data exclusively over Germany, you must explicitly configure an Area of Interest (AOI) spatial boundary in all search queries.
Updated Service URLs & Endpoints
Some features may still be in the final stages of deployment.
| Service | URL / Endpoint | IP Address | Description |
|---|---|---|---|
| Tenant Manager | tenant-manager.code-de.org | 45.92.243.120 | User profile, contract & wallet management |
| S3 Endpoint | eodata.code-de.org | 91.234.53.164 | Access to EO data via S3 |
| S3 Endpoint | s3.fra1-3.cloudferro.com | 74.63.12.97 | Access to private S3 buckets |
| OData Catalogue | catalogue.code-de.org | 185.48.233.110 | OData catalogue API |
| STAC Catalogue | stac.code-de.org | 74.63.12.5 | STAC catalogue API (primary recommended) |
| Portal | code-de-lab.org | — | The CODE-DE-Lab website |
| Forum | forum.code-de.org | — | User discussion forum |
| Knowledgebase | knowledgebase.code-de.org | — | Self-help portal and documentation |
| Keycloak — Identity Provider | identity.cloudferro.com | — | Authentication / Authorization |
| Enhanced Data Viewer | Not yet available | — | — |
| openEO | Not yet available | — | — |
| Data Explorer | Not yet available | — | Data search and download |
| JupyterLab | Not yet available | — | Python experimentation (on request) |
Frequently Asked Questions
What will happen to my Thermal / RESA / Orthophoto data access after the migration?
Due to necessary technical updates and the enhanced security architecture of the new platform, all previous access permissions for Thermal, RESA, and Orthophoto data will be reset.
Users will be required to submit a new request through the updated portal. This will be a straightforward process within the familiar Tenant Manager application.
There will be limitations on data egress — what does that mean?
To ensure a stable environment for all users, data egress management is being implemented based on a Fair Use Policy. The monthly limit for downloading data to external networks depends on request rate, bandwidth limit, and total monthly transfer volume (in TB). Data moved within the CODE-DE-Lab environment is not subject to any limitations.
Users will be assigned different quota roles, with specifics communicated in due course. Additional capacity can be requested and will be reviewed by the DLR.
When will EnMAP data be available on the platform?
Work is ongoing to finalize all necessary technical and legal requirements. All platform users will be notified via the website and newsletters once available. The data has already been transferred to the new cloud environment, so publication is expected soon.
In the meantime, data are available on the EOC-Geoservice platform. CODE-DE-Lab users can access them via Identity Federation using their CODE-DE-Lab credentials directly on the EOC UMS.
Do the STAC and OData catalogues contain the same data?
No. Due to operational circumstances, the two catalogues differ slightly in their contents and update cycles. Search results for the same collection may return slightly different responses.
We advise using the STAC catalogue as the primary source of information.
I have a running Kubernetes cluster (K8s). What do I need to do for the migration?
Please contact the support team directly for guidance specific to your Kubernetes setup. Reach out via support@code-de.org or the ticket system in Tenant Manager.
Why is Sentinel data no longer hosted on CODE-DE-Lab directly?
The transition was made for two key reasons. First, it saves an immense amount of storage space — duplicating massive datasets like Sentinel is no longer a sustainable approach. Second, by fetching data directly from the primary source (CREODIAS), the risk of synchronization delays or data gaps is eliminated.
How can I access data from New Space providers like Planet Labs, OroraTech, or constellr?
CODE-DE-Lab provides access to these datasets, which are protected by export restrictions and/or special licensing agreements. Access is on-demand and requires approval by DLR.
To apply, go to Tenant Manager → Support → Data Application. Create a new request and choose the data you wish to apply for.
What does the new CODE-DE-Lab resource policy entail?
Specific details are still being finalized, but all projects will be evaluated according to a consistent, transparent evaluation scheme to ensure fair distribution of resources. Large-scale resources remain abundant. Specifics will be communicated after the migration process. Resources can also be acquired directly by users — a framework agreement is in progress.
Why is the platform called CODE-DE-Lab?
CODE-DE-Lab is a combination of the two previous platform names (CODE-DE and EO-Lab), representing the unified national EO data platform. It combines the strengths of both predecessors and offers a unique data catalogue, powerful computing resources, and strong user support.
Where is CODE-DE-Lab hosted physically?
CODE-DE-Lab is located on a public cloud operated by CloudFerro in Frankfurt, Germany. The data center is fully BSI / C5 certified.
Why is JupyterLab only available on request?
Previously, open unmoderated access to JupyterLab was frequently exploited for unauthorized activities. A moderated access model has been implemented to protect the platform’s integrity. In return, approved users receive high-performance GPU support completely out of the box.
How can I authenticate on CODE-DE-Lab services without the GUI?
You can use token-based authentication, following the instructions from the Knowledgebase: Authenticating to OpenStack SDK using Keycloak Credentials.
However, please make sure you replace the Keycloak URL in the article with the new CODE-DE-Lab one:
https://identity.cloudferro.com/auth/realms/CODE-DE3/protocol/openid-connect/token
Note: The Knowledgebase article will be updated in the coming weeks.
Where can I find the so-called Convenience Products?
As part of the ongoing modernisation and optimisation of our platform, a number of older, internally generated datasets — our so-called “Convenience Products” — have been removed from the active catalogue with immediate effect.
As these specific products were only actively used by a very small number of projects, we implemented this step at short notice and without the usual advance notice, in order to free up resources for higher-performance, standardised data offerings. We sincerely apologise for any inconvenience this may have caused.
Where can I access the digital orthophotos and 3D mesh data previously hosted on CODE-DE?
These data are now included with all the other EO data on CODE-DE-Lab. You can find them without an additional request under the following path:
/eodata/codede-aerial-surveys
Known Issues
We are actively working on the issues listed below. If you are experiencing one of them, please open a support ticket — we will notify you as soon as a solution is available.
No NVMe SSDs available for A100 GPU instances
As part of the migration to our new infrastructure, there is a technical change regarding the storage architecture: on the new platform, the local NVMe SSDs that were previously coupled with the A100 GPU cards are no longer available in this specific configuration. Consequently, these SSD storage drives could not be automatically transferred 1:1 during the VM migration.
To ensure that no data is lost, please perform the following manual check:
- Log in to your old VM and run the following command to check if you were actively using this NVMe storage:
mount | grep nvme - If the command returns a result, please copy the data stored there to the new environment yourself, using tools such as rclone or similar transfer utilities.
Important: If you detect active data on an NVMe SSD, please contact us immediately so we are aware of your situation. Also send us a brief notification once you have successfully completed the data migration.
Please be assured that the old infrastructure will remain active until this process is complete, giving you sufficient time for the transfer. Since we as the platform operator do not have insight into your operating system configurations, this manual check is the safest and most efficient path forward.
“No valid host found” error for vgpu.a6000.48gb GPU flavor
The GPU flavor vgpu.a6000.48gb on FRA1-3 is currently returning a “No valid host found” error. New compute nodes with physical GPUs will be added shortly. Until then, customers may experience issues when launching VMs with this 48 GB GPU flavor.
