Skip to main content
Tensor9 enables the secure and reliable deployment of vendor application artifacts (such as container images and models) into customer-connected appliances using Infrastructure as Code (IaC). Artifacts are the essential files needed for your application to run. Tensor9 focuses on two primary artifact kinds:
  1. Files in an object store (e.g., S3 objects) 
    resource "aws_lambda_function" "example_lambda" {
   function_name = "example-function"
   s3_bucket     = "example-bucket"
   s3_key        = "example-key"
   handler       = "index.handler"
   runtime       = "nodejs24.x"
   role          = aws_iam_role.example_lambda_role.arn
}
  2. Container images (stored in ECR) 
    resource "kubernetes_manifest" "example_deployment" {
   manifest = {
      "apiVersion" = "apps/v1"
      "kind"       = "Deployment"
      "metadata" = {
         "name"      = "example-deployment"
      }
      "spec" = {
         "replicas" = 2
         "selector" = {
            "matchLabels" = {
               "app" = "example-app"
            }
         }
         "spec" = {
            "containers" = [{
               "name"  = "example-container"
               "image" = "123456789012.dkr.ecr.us-west-2.amazonaws.com/example-image:example-tag"
               "ports" = [{
                  "containerPort" = 80
               }]
            }]
         }
      }
   }
}

​
Artifact deployment strategies

Tensor9 supports two primary strategies for moving artifacts from the vendor’s source environment to the customer’s appliance environment: Copy during deployment or direct reference. In the Copy model, the Vendor Controller copies the artifact from the vendor’s source location to a dedicated artifact repository within the customer’s appliance account during the deployment process. In this model, only the Vendor Controller requires read access to the artifacts and the vendor does not have to grant read permissions for each artifact to every appliance.
ScenarioDescriptionTensor9 Action
Deploy-Time ArtifactsArtifacts needed for the infrastructure resource definition (e.g., a Container Image referenced in an ECS Task Definition or a Lambda function zip archive in S3).Tensor9 automatically detects the artifact in your Terraform, copies it to the appliance account, and updates your compiled code to point to the new, local location.
Run-Time ArtifactsArtifacts referenced at runtime (e.g., an LLM Model in S3) that need to be available in the appliance.You use a separate, dedicated Terraform stack that defines the S3 data source. Tensor9 copies the artifact as part of the apply step.

​
Vendor workflow (container image copy):

  1. Your CI/CD builds the container image and publishes it to your origin ECR repository.
  2. Your Terraform references the image using its full path/tag in your compute resource definition (e.g., resource.aws_ecs_task_definition.container_definitions[*].image).
  3. When you run the Tensor9 build and apply steps, the compiler:
    • Identifies the artifact reference.
    • Creates a process to copy the artifact from your ECR to the appliance’s ECR.
    • Rewrites your compiled infrastructure resource to reference the new, appliance-local ECR path.

​
2. Direct reference model: Override

In the Direct Reference model the artifact is not copied. The appliance is configured to reach out and pull the artifact directly from the vendor’s source location. This model is generally reserved for special cases, such as:
  • Publicly accessible artifacts from sources trusted by both the vendor and the customer.
  • Extremely large artifacts where minimizing data transfer/copy costs through the Vendor Controller account is critical.
  • Artifacts that the vendor only wants to access dynamically at runtime.
ActionVendor Requirement
Override DefaultYou must provide an annotation in your IaC to explicitly tell the Tensor9 compiler to skip copying a specific artifact reference.
PermissionsYou are responsible for managing cross-account permissions (e.g., setting up appropriate IAM roles/policies) to ensure the customer’s appliance can read the artifact directly from your vendor source account.

​
Copy during deployment details

​
Artifact naming requirements

To ensure immutability and prevent race conditions during deployments, Tensor9 requires all vendor artifacts to be uniquely named and immutable.
Artifact TypeNaming RequirementWhy?
S3 ObjectsApply a version scheme to the S3 key/filename.Ensures that a deployment always receives the same, specific artifact version, even during rollbacks.
ECR ImagesApply a version scheme to the ECR tag.Mutable tags (like :latest) can change, leading to inconsistent deployments. Use immutable tags for reliability.
By enforcing immutable naming, we ensure a deployment to an appliance is always linked to a known-good application version.

​
Supported artifact locations

Tensor9 supports copying artifacts from two locations within the vendor’s control:
Origin LocationProsCons
Vendor Controller AccountTensor9 manages the necessary permissions for appliances to read and copy artifacts.Requires the vendor to replicate the artifact into this account before initiating deployment.
Another Vendor-Owned AccountDirectly reference artifacts where they are used.Requires the vendor to manually create roles that the Tensor9 controller can assume to perform the copy operation. May also increase transfer costs by copying once to the Vendor Controller account then on to the customer account.

​
Out-of-scope artifacts

Tensor9 does not directly manage the following artifact types:
  • Secrets (handled by Tensor9 Secret Management)
  • Code repositories (GitHub, CodeCommit, etc.)
  • Package mirrors (Maven, NPM, etc.)
  • Database data
Note: You can, however, export data from these sources as inert files (e.g., a database snapshot) and copy them as S3 objects.