Imagine your infrastructure pipeline is running perfectly . . . until it isn’t. You apply a routine security patch to a Terraform module, review the plan, and hit approve. Everything looks fine in the logs. But ten minutes later your phone rings. The director of customer support is livid. Customers are flooding her team with calls over orders processing incorrectly. When you investigate, you discover that a two-day-old version of the application was quietly re-deployed, reverting critical business logic changes, without a single alert. You had no idea. But now, you are responsible for cleaning up a customer-facing, revenue-impacting mess. This is the result of version drift, the inevitable consequence of two deployment systems that do not share a source of truth.
The good news is that this version drift is preventable. Part 1 of this series describes the Terraform side of the solution, the SSM Registry Pattern. [Link to Part 1 to be added when published.] Instead of hardcoding application versions in the infrastructure code, the pattern reads them live from AWS Systems Manager Parameter Store at apply time. SMS’s DevOps managed services implemented this pattern working closely with Gridline, a financial technology firm, and it is now running in their production environment. However, Terraform can only read what the application CI writes. This post covers that side of the pattern. It details the GitHub Actions workflow that updates the registry after every successful deployment and the infrastructure pipeline that reads from it before each Terraform apply.
The following diagram shows how the workflows leverage SSM Parameter Store as a version registry:
The version registry only works if something writes to it. That responsibility belongs to the application CI.
After every successful deployment, the application workflow writes the deployed version to SSM. For an ECS service, the version is the Git commit SHA used as the image tag. For a Lambda function, it is the S3 object key of the deployment package. The write happens after the artifact is confirmed deployed, not before, not speculatively. If the deployment fails, SSM is not updated. The registry always reflects a version that is known to have deployed successfully.s own pace.
This is the contract between the two systems. The application CI owns the write. The infrastructure code owns the read. Neither system reaches into the other’s territory.pull request.
The code samples in the following sections come from a companion repository with a full working implementation. Here’s the full deploy-api.yml workflow:
name: Deploy API
on:
push:
branches: [main]
paths: [“apps/api/**”]
workflow_dispatch:
# In a real setup, apps/api/ would live in its own repository and this
# workflow would be at the root of that repo. It is co-located here for
# the purposes of the blog sample.
permissions: {}
jobs:
deploy:
runs-on: ubuntu-latest
env:
IMAGE_TAG: ${{ github.sha }}
permissions:
id-token: write # required for OIDC role assumption
contents: read
steps:
– name: Checkout
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
– name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@ec61189d14ec14c8efccab744f656cffd0e33f37 # v6.1.0
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: ${{ vars.AWS_REGION }}
– name: Log in to Amazon ECR
id: ecr-login
uses: aws-actions/amazon-ecr-login@19d944daaa35f0fa1d3f7f8af1d3f2e5de25c5b7 # v2.1.4
– name: Build and push container image
env:
ECR_REGISTRY: ${{ steps.ecr-login.outputs.registry }}
run: |
if aws ecr describe-images \
–repository-name “${{ vars.PROJECT_NAME }}-api” \
–image-ids “imageTag=$IMAGE_TAG” > /dev/null 2>&1; then
echo “Image $IMAGE_TAG already exists in ECR — skipping build and push”
else
docker build \
–platform linux/amd64 \
–tag “$ECR_REGISTRY/${{ vars.PROJECT_NAME }}-api:$IMAGE_TAG” \
./apps/api
docker push “$ECR_REGISTRY/${{ vars.PROJECT_NAME }}-api:$IMAGE_TAG”
fi
– name: Register new ECS task definition revision
id: register-task
env:
ECR_REGISTRY: ${{ steps.ecr-login.outputs.registry }}
run: |
CURRENT=$(aws ecs describe-task-definition \
–task-definition “${{ vars.PROJECT_NAME }}-api” \
–query taskDefinition \
–output json)
# Select the target container by name so sidecars do not interfere.
UPDATED=$(echo “$CURRENT” | jq \
–arg IMAGE “$ECR_REGISTRY/${{ vars.PROJECT_NAME }}-api:$IMAGE_TAG” \
–arg NAME “api” \
‘del(.taskDefinitionArn,.revision,.status,.requiresAttributes,.compatibilities,.registeredAt,.registeredBy)
| (.containerDefinitions[] | select(.name == $NAME)).image = $IMAGE’)
TASK_DEF_ARN=$(aws ecs register-task-definition \
–cli-input-json “$UPDATED” \
–query taskDefinition.taskDefinitionArn \
–output text)
echo “task_def_arn=$TASK_DEF_ARN” >> “$GITHUB_OUTPUT”
– name: Update ECS service
run: |
aws ecs update-service \
–cluster “${{ vars.PROJECT_NAME }}-cluster” \
–service “api” \
–task-definition “${{ steps.register-task.outputs.task_def_arn }}”
aws ecs wait services-stable \
–cluster “${{ vars.PROJECT_NAME }}-cluster” \
–services “api”
– name: Write version to SSM
run: |
aws ssm put-parameter \
–name “/app/${{ vars.ENVIRONMENT }}/versions/api” \
–value “$IMAGE_TAG” \
–type “String” \
–overwrite
A few things are worth calling out.
Action versions are pinned to SHA hashes. Each uses: line references a 40-character commit SHA rather than a mutable version tag. A version tag like v4 can be moved to point to different code at any time. A SHA is immutable. This is a supply chain security practice. If a tag is compromised after you pin it, your workflow is unaffected. With supply chain attacks against open-source actions becoming increasingly common, this practice meaningfully reduces your exposure.
AWS authentication uses OIDC. The configure-aws-credentials action assumes an IAM role via the GitHub OIDC provider rather than using long-lived access keys stored as secrets. The role is scoped to the specific AWS actions the workflow requires. No AWS credentials are stored in GitHub. The README.md in the companion repository covers this in additional detail.
The SSM write happens last, after the ECS service is confirmed stable. This is the registry contract. SSM reflects a version that has been successfully deployed, not just built or pushed. If the ECS update fails, the workflow stops and SSM is not updated. The previous SSM value, pointing to the last known good deployment, remains in place.
Task definition registration uses jq to swap the image. The workflow fetches the current task definition, strips the read-only fields that would cause the registration to fail, replaces the image on the target container by name, and registers a new revision. Selecting the container by name rather than by index means the logic is safe when sidecars are present.
The full deploy-processor.yml workflow:
name: Deploy Processor
on:
push:
branches: [main]
paths: [“apps/processor/**”]
workflow_dispatch:
# In a real setup, apps/processor/ would live in its own repository and this
# workflow would be at the root of that repo. It is co-located here for
# the purposes of the blog sample.
permissions: {}
jobs:
deploy:
runs-on: ubuntu-latest
env:
IMAGE_TAG: ${{ github.sha }}
permissions:
id-token: write # required for OIDC role assumption
contents: read
steps:
– name: Checkout
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
– name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@ec61189d14ec14c8efccab744f656cffd0e33f37 # v6.1.0
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: ${{ vars.AWS_REGION }}
– name: Package Lambda function
working-directory: apps/processor
run: zip “processor-${IMAGE_TAG}.zip” handler.py
– name: Upload package to S3
run: |
aws s3 cp \
“apps/processor/processor-${IMAGE_TAG}.zip” \
“s3://${{ vars.PROJECT_NAME }}-lambda-packages/processor-${IMAGE_TAG}.zip”
– name: Update Lambda function code
run: |
if aws lambda get-function –function-name “${{ vars.PROJECT_NAME }}-processor” > /dev/null 2>&1; then
aws lambda update-function-code \
–function-name “${{ vars.PROJECT_NAME }}-processor” \
–s3-bucket “${{ vars.PROJECT_NAME }}-lambda-packages” \
–s3-key “processor-${IMAGE_TAG}.zip”
aws lambda wait function-updated \
–function-name “${{ vars.PROJECT_NAME }}-processor”
else
echo “Lambda function does not exist yet — skipping update. Terraform will deploy it on the next infra-apply.”
fi
– name: Write version to SSM
run: |
aws ssm put-parameter \
–name “/app/${{ vars.ENVIRONMENT }}/versions/processor” \
–value “processor-${IMAGE_TAG}.zip” \
–type “String” \
–overwrite
The structure mirrors the ECS workflow. It packages the function, uploads to S3, updates the function, and writes the S3 object key to SSM only after the update is confirmed.
The S3 key written to SSM is the full object key, processor-<sha>.zip, not just the SHA. Terraform’s s3_existing_package block needs the full key, so that is what the registry stores.
The update-function-code step checks whether the Lambda function exists before attempting the update. This handles the bootstrap scenario. On initial setup or after a full teardown, the Lambda function does not exist until Terraform creates it. The S3 upload completes successfully, giving Terraform everything it needs to create the function on its next apply, and SSM is written after the artifact is in place so it reflects only versions that have been confirmed deployed. In normal operation, the function exists and the update runs unconditionally.
This workflow updates $LATEST directly. Teams using Lambda aliases for blue/green or weighted traffic shifting will need to extend the pattern to also track the published version number alongside the S3 key.
Terraform stores the output of the version registry module in state. The version_map output, a map of service names to deployed versions, is persisted to the state file on each apply.
Between infrastructure applies, the application CI may deploy new versions and update SSM. Terraform’s state still reflects the versions from the last apply. If the infra pipeline runs a full terraform apply without first refreshing the registry module, Terraform computes its plan using the stale values in state. The plan may show a spurious diff on the image tag or Lambda S3 key, or in the case of the Lambda module, it may attempt to reconcile to a version that no longer matches what CI has deployed.
The fix is a targeted apply on the version registry module before the full apply:
terraform apply -target=module.version_registry -auto-approve
terraform apply -auto-approve
The targeted apply reads the current SSM parameters and updates state. The full apply that follows computes its plan from the refreshed values. The deployed versions in SSM match what is actually running, so the plan shows no diff on image tags or S3 keys.
In this sample, the targeted apply is not strictly necessary because the version registry module lives in the same Terraform root as the rest of the infrastructure. A plain terraform apply would read SSM directly and arrive at the same result. The two-step apply sequence is included because it reflects the pattern you would need to follow in a real-world setup where the version registry is deployed as a separate unit. In that case, the registry must be applied first so its outputs are available to the deployments that depend on them. HashiCorp flags -target as appropriate for exactly this kind of scenario where it is necessary to refresh data inputs that downstream resources depend on at plan time.
The full infra-apply.yml workflow:
name: Apply Infrastructure
on:
push:
branches: [main]
paths: [“infra/**”]
workflow_dispatch:
# Prevent concurrent applies. cancel-in-progress: false means a second
# triggered run queues rather than cancels, so no two applies ever race
# on the same state file. This removes the need for a DynamoDB lock table.
concurrency:
group: terraform-apply
cancel-in-progress: false
permissions: {}
jobs:
apply:
runs-on: ubuntu-latest
permissions:
id-token: write # required for OIDC role assumption
contents: read
steps:
– name: Checkout
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
– name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@ec61189d14ec14c8efccab744f656cffd0e33f37 # v6.1.0
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: ${{ vars.AWS_REGION }}
– name: Setup Terraform
uses: hashicorp/setup-terraform@5e8dbf3c6d9deaf4193ca7a8fb23f2ac83bb6c85 # v4.0.0
with:
terraform_version: “1.5.7”
– name: Terraform init
working-directory: infra
run: |
terraform init \
-backend-config=”bucket=${{ vars.TF_STATE_BUCKET }}” \
-backend-config=”key=terraform.tfstate” \
-backend-config=”region=${{ vars.AWS_REGION }}”
# Apply the version registry first. This refreshes Terraform’s view of
# the SSM parameters so that the current deployed versions — written by
# application CI — are in state before anything else is planned or applied.
# Without this step, Terraform’s state can lag behind the live SSM values
# and produce a spurious diff on the image tag or Lambda S3 key.
– name: Refresh version registry
working-directory: infra
run: terraform apply -target=module.version_registry -auto-approve
– name: Apply all infrastructure
working-directory: infra
run: terraform apply -auto-approve
Two design decisions are worth explaining.
The S3 backend uses partial configuration. The main.tf file contains only backend “s3” {} with no bucket name or region. Those values are passed as -backend-config flags at terraform init time, read from GitHub Actions variables. This keeps environment-specific values out of source control and makes the sample portable. Anyone can clone it, set their own TF_STATE_BUCKET variable, and run it without modifying any Terraform files. In production, this pattern also makes it straightforward to use different state buckets per environment without branching the Terraform code. key.
Concurrent applies are prevented with a concurrency group. The cancel-in-progress: false setting means a second workflow run triggered while one is already running will queue rather than cancel. No two applies ever race on the same state file. This sample does not use a DynamoDB lock table. Terraform 1.5.x requires DynamoDB for S3 backend locking, and Terraform 1.10+ adds native S3 locking without DynamoDB. For a single-environment sample, the GitHub Actions concurrency group provides equivalent safety without the additional infrastructure. Production setups running Terraform 1.5.x should add a DynamoDB table.ied is increasingly out of date.
A reader familiar with Terraform will reach for ignore_changes as a solution to version drift. Two variants come up in practice, and both are worth addressing.
The first is ignore_changes = [task_definition] on the ECS service resource. This prevents Terraform from reverting the service to an older task definition revision after the application CI has deployed a newer one. The version drift problem appears to go away. However, the stale version is still hardcoded in the Terraform file. Remove ignore_changes and the drift comes back on the next apply. It is not a fix. It is Terraform looking away.
The second is ignore_changes = [container_definitions] on the task definition resource itself. This prevents Terraform from registering new revisions when the image changes, which stops the rollback. However, it also stops any legitimate image update through Terraform. If you need to change the container image for any reason, such as updating a base image, patching a vulnerability, or onboarding a new service, Terraform cannot help you. The task definition’s most important attribute is now effectively unmanaged. You have not solved the problem. You have hidden it.
There is a deeper problem with both variants. Lifecycle blocks in Terraform cannot reference variables or expressions and must be statically defined. This means a module author cannot expose ignore_changes as behavior that consumers opt into.
In practice, production infrastructure code uses community-vetted modules rather than raw resources. Writing your own Terraform modules from scratch is rarely the right call when the ecosystem already provides well-tested options. This sample uses raw resources for the ECS task definition and service to keep the code readable, but the Lambda function is managed through a public module. That is precisely the point. You cannot add a lifecycle block to a resource inside that module. The workaround that appeared to work for the raw ECS resources is not available at all for Lambda without forking the module or dropping down to raw resources yourself. It is not a pattern that scales.
The SSM registry solves the actual problem. It replaces the stale hardcoded version with a live lookup, so Terraform’s plan reflects what is actually running. There is nothing to suppress.
This division is deliberate. Terraform remains the source of truth for every other aspect of the task definition, including CPU, memory, environment variables, and the task role. The SSM registry handles the one attribute that the application CI owns, the image. Without ignore_changes, infrastructure applies that touch the task definition will trigger an ECS rolling update. Because the image comes from SSM and reflects what is actually running, ECS replaces old containers with new ones running the same image, waits for them to be healthy, and drains the old ones. This is what ECS is designed to do.
On first apply after a fresh deployment, the plan output for the Lambda function will show a change on the S3 key:
# module.processor.aws_lambda_function.this[0] will be updated in-place
~ resource “aws_lambda_function” “this” {
~ s3_key = “processor-abc1234def5.zip” -> “processor-def5678abc1.zip”
}
This is the pattern working correctly. The version registry refresh read the current key from SSM, written by deploy-processor, and updated state. The full apply reconciles the Lambda function to match. On subsequent applies where no deployment has occurred, this diff does not appear.with a live lookup.
The ECS task definition shows a similar reconciliation on first apply:
# aws_ecs_task_definition.api must be replaced
-/+ resource “aws_ecs_task_definition” “api” {
~ container_definitions = “[{\”image\”:\”…api:abc1234\”,…}]” -> (known after apply) # forces replacement
~ revision = 7 -> (known after apply)
}
Terraform registers a new task definition revision with the SHA from SSM and updates the ECS service to point to it. As described in the previous section, ECS performs a rolling update. New containers running the same image are health-checked and the old ones are drained. After this first reconciliation, subsequent applies where the SHA has not changed produce no diff.
Two options are available when a bad deployment needs to be undone.
The faster option is to re-run the deployment workflow against a known-good commit SHA. Pass the target SHA as a workflow input or manually trigger the workflow from a specific commit. The workflow builds the old image, pushes it, writes the SHA to SSM, and updates ECS or Lambda. Terraform is not involved.
The alternative for ECS is to repoint the service directly to an earlier task definition revision using the AWS CLI:
aws ecs update-service \
–cluster <cluster-name> \
–service <service-name> \
–task-definition <family>:<revision>
aws ecs wait services-stable \
–cluster <cluster-name> \
–services <service-name>n.
This gets the service running the old code immediately. Follow it with a re-run of the deployment workflow against the known-good SHA to update SSM and restore consistency. If SSM is left pointing to the bad SHA, the next infrastructure apply will reconcile toward it.
SSM Parameter Store retains the history of every value written to a parameter. The AWS console shows version history with timestamps under the parameter’s history tab, though it may not display the value for each historical version. The full sequence of deployed SHAs, including values, is reliably available via aws ssm get-parameter-history. Either way, you get a timestamped record of every deployment without any additional tooling.at need a version reference.
SSM Standard parameters are free. There is no charge for storing parameters, reading them with GetParametersByPath, or writing to them with PutParameter. The version registry adds no cost to running this pattern.
There is a narrow timing window between the version registry refresh and the full apply during which a deploy workflow could complete and write a newer version to SSM. If that happens, the full apply uses the version the refresh captured. The next infrastructure apply will reconcile forward correctly. In practice this window is seconds wide, but it is worth knowing about if the infra pipeline and a deploy workflow are triggered simultaneously.
The SSM write is the last step in each deploy workflow and is not retried on transient failure. If it fails after a successful deployment, the running service is at the new version but SSM still reflects the old one. The next infrastructure apply will reconcile toward the stale SSM value. Monitoring the SSM write step and alerting on failure closes this gap.
Adding a service to the registry requires two steps. The application CI workflow writes its version to an SSM parameter under the shared path prefix, and the infrastructure code adds a lookup on module.version_registry.version_map for the new service name. The registry module reads all parameters under the prefix in a single API call. A new service appears in the map automatically on the next apply after its first deployment writes to SSM. There is no list of service names to maintain in the Terraform code.
The sample repository consolidates what would normally be three separate repositories (infrastructure, API application, and processor) into a single repo for clarity. In production, each application repository carries its own deployment workflow. The infrastructure repository is separate. The SSM path prefix provides the coordination point between them.
Gridline‘s production implementation runs this pattern across multiple application repositories and AWS environments. The SSM Registry Pattern eliminated the risk of an incident caused by an infrastructure apply overwriting a live deployment. The core module is identical to what is described in this series. The operational scaffolding around it, including environment promotion, pipeline sequencing, and state management, is handled by the surrounding CI infrastructure.
The full working sample, verified against a live AWS environment, is at github.com/sms-data-products/blog-terraform-ssm-version-registry.
The two posts in this series trace the SSM Registry Pattern from both sides of the deployment boundary.
Part 1 replaced hardcoded application versions in Terraform with live lookups from SSM, eliminating version drift as a source of silent rollbacks. Part 2 wired up the application workflows that keep SSM current and the infrastructure pipeline that reads from it before applying.
With both in place, application deployments and infrastructure changes run on independent schedules; however, they stay in sync. A module version bump generates a plan that shows only what the bump changes. Application versions are not in the diff.
The natural extensions from here are environment promotion, deliberately writing a validated version to a staging or production SSM path, and adding new services, each of which requires only a deployment workflow that writes to SSM and a lookup in the infrastructure code.
The full working sample, verified against a live AWS environment, is at github.com/sms-data-products/blog-terraform-ssm-version-registry.
Disclaimer: The code samples and architecture described in this post are drawn from a public sample repository at github.com/sms-data-products/blog-terraform-ssm-version-registry, built to illustrate the pattern. They do not represent Gridline‘s actual production configuration.
Gridline is a turnkey private markets platform built to set a new standard for how RIAs operate, manage, and scale alternatives.
We partner with RIAs to make private markets operate as simply as public markets.
Our portfolio management capability gives advisors real-time visibility across every client and every investment, so you’re not waiting on quarter-end reports to understand exposures, performance, or cash flow dynamics. You can drill down by client, fund, or strategy to see the full picture, strengthen transparency, and make faster, better-informed decisions with confidence.
Because the data is always current, meeting prep shrinks and client conversations elevate. Reports are ready when you are. They are clear, accurate, and easy to share, turning portfolio complexity into insight clients can trust.
Where most solutions layer tools on top of fragmented workflows, Gridline is built as core infrastructure: one system that runs the full private markets lifecycle. Gridline centralizes every commitment, capital call, valuation, distribution, and document into a single, always-on source of truth, replacing spreadsheets, portals, and PDFs with an always-on, always-up-to-date source of truth that’s available the moment you need it.
The result is a competitive edge that helps you scale, differentiate your firm, and deliver a modern client experience.
This is what it means to set a new standard for alternative investing.
Book a call to see how Gridline helps you scale alternatives without scaling complexity.
Christopher Jones is a Senior Software Engineer at Gridline specializing in resilient, high-performance back-end systems for the financial industry. Since transitioning into software engineering in 2020, he has focused on building reliable, scalable software and infrastructure for mission-critical environments. He developed deep expertise in Infrastructure as Code by creating engineering patterns that improve operational reliability, consistency, and long-term maintainability.
Rob Stewart has over 25 years of experience driving technology innovation. As a cloud architect at SMS, he spearheads the design and implementation of cutting-edge cloud solutions for government and private sector customers, unlocking efficiency and scalability. Prior to SMS, Rob led a global team developing a learning management platform deployed on AWS and was instrumental in driving the adoption of modern devops practices resulting in a dramatic increase in the consistency of software delivery. He is an accredited expert in cloud technologies, with multiple AWS, Azure and Kubernetes certifications. In his free time, he enjoys spending time with his family and two cats.
Imagine this scenario. An infrastructure engineer upgrades the ECS cluster Terraform module from version 5.11.4 to 5.12.0. Routine change. They run terraform apply, review the plan, approve it. Thirty seconds later, the API service is running code from three weeks ago.
No alert fired. No obvious error. A deployment that shipped this morning, validated in staging, approved by the team, carrying a critical fix, has been quietly undone.
This is version drift. It is silent until it causes an incident, and it is a real risk for any team that manages application deployments separately from infrastructure. The good news is that it is entirely preventable.
This post explains why it occurs and introduces the SSM Registry Pattern, the solution that SMS’s DevOps managed services implemented for Gridline, which is now running in their production environment.
The split between application repositories and infrastructure repositories is a natural consequence of scale.
When you have one service and one team, keeping everything in one place is manageable. When you have a dozen services, each deployed independently by its own team, and a separate infrastructure practice managing the underlying platform, the split is the right call. Application code and infrastructure code change on different schedules, have different reviewers, and carry different risks. Separating them gives each team the autonomy to move at its own pace.
In this model, application deployments bypass Terraform entirely. When an application team pushes a new container image, their CI pipeline builds it, tags it with the commit SHA, pushes it to ECR, and updates the ECS service directly. For a Lambda function, the pipeline zips the package, uploads it to S3, and updates the function. Terraform is not involved. That is by design. Routine application deployments should not require an infrastructure pull request.
However, the infrastructure repository still references those application versions. The ECS task definition must point to a container image. The Lambda function configuration must reference a deployment package. Before the split, both lived in the same codebase and were updated together. After the split, the infrastructure code holds a reference to a version it no longer controls.
Gridline, a financial technology firm running multiple application repositories alongside a mature infrastructure as code setup built on Terraform, recognized that version drift was creating friction as their infrastructure grew. Their team was doing everything right. They had separate repos for application code and infrastructure, CI/CD for both, and versioned Terraform modules pinned across all environments. But the risk of a silent rollback introduced hesitation into every infrastructure change. Engineers had to manually verify deployed versions before applying, slowing down what should have been routine updates. The version drift problem was not a discipline failure. It was an inevitable consequence of two deployment systems that did not share a source of truth. Solving it gave their teams the freedom to deploy infrastructure updates with confidence that application versions would never be silently overwritten.onger controls.
Application deployments and infrastructure changes run on fundamentally different schedules.
Application teams deploy frequently. Multiple times per day is common in healthy engineering organizations. Each deployment pushes a new version to the running service without touching the infrastructure code.
Infrastructure changes are less frequent by comparison. A module version upgrade, a security group update, a new IAM policy, a configuration change. When they happen, an engineer runs terraform plan, reviews the output, and applies.
The drift happens at the intersection of these two timelines. Between any two infrastructure applies, the application team has deployed any number of new versions. As soon as the running application version is updated, the Terraform code is out of date because it still references the version that was current the last time anyone ran terraform apply. The next infrastructure change, which may come days or weeks later due to a Terraform module update that addresses a security concern or supports a new configuration option, triggers a plan that includes resetting the service to the old version.
Gridline faced this risk directly after migrating their ECS services and Lambda functions to independent application repositories. With application deployments now running independently of Terraform, any infrastructure change carried the potential for a silent rollback. That meant Gridline faced additional risk any time an infrastructure update was performed.
Understanding why this happens requires a clear picture of how Terraform computes a plan.
When Terraform plans an ECS update, it refreshes its state by querying AWS, then compares the refreshed state against the desired state in your .tf files. When there is a hardcoded image tag but the application CI has deployed a newer version, the live ECS service points to a task definition revision that Terraform does not manage. Terraform plans to revert the service to the revision in its state, which still carries the stale image tag. If something else in the task definition has also changed (environment variables, CPU or memory, or the task role), Terraform may register a new revision in the process, but it will carry the stale tag either way. The running container is rolled back to an older version.
The same applies to Lambda functions. When Terraform plans a Lambda update, the application CI has already uploaded a new package to S3 and updated the function. Terraform refreshes and reads the current S3 key from AWS. That value differs from the hardcoded key in the Terraform code. Terraform plans to update the function back to the stale key.
This is not a bug in Terraform. It is a consequence of using Terraform to manage resources that another system is also updating. The state file accurately reflects what Terraform last applied. The problem is that what Terraform last applied is increasingly out of date.
The core problem is that the image tags are hardcoded in infrastructure code. Subsequent application deployments make them stale. Any infrastructure apply carries the risk of silently rolling back application deployments to an outdated version.
The problem looks like this:
The fix is to make Terraform read the live deployed version instead of storing a hardcoded one.
AWS Systems Manager Parameter Store serves as the bridge. The application CI writes the deployed version to an SSM parameter immediately after each successful deployment. The version is the container image SHA for ECS services or the S3 object key for Lambda packages. The infrastructure code reads those parameters at apply time using a small Terraform module called the version registry. The hardcoded version is replaced with a live lookup.
The SSM Registry Pattern treats Parameter Store as the single source of truth for deployed application versions, making Terraform a consumer of that truth rather than a holder of a stale copy.ne they need to pause.
When an infrastructure engineer bumps a module version and runs terraform apply, the version registry module reads the current SHA from SSM. The plan reflects the live deployed state. The modifications that are part of the module upgrade show up as changes, but the image tag does not. pause.
The solution looks like this:
The code samples in the following sections come from a companion repository with a full working implementation. The version registry module is small by design. Its only job is to read all SSM parameters under a given path prefix and return them as a map via a Terraform output:
# infra/modules/version-registry/main.tf
variable “ssm_path” {
description = “SSM path prefix to read versions from, e.g. /app/dev/versions/”
type = string
}
data “aws_ssm_parameters_by_path” “versions” {
path = var.ssm_path
}
output “version_map” {
description = “Map of service name to deployed version”
value = {
for i in range(length(data.aws_ssm_parameters_by_path.versions.names)) :
basename(data.aws_ssm_parameters_by_path.versions.names[i]) =>
data.aws_ssm_parameters_by_path.versions.values[i]
}
}
aws_ssm_parameters_by_path reads every parameter under the given prefix in a single API call. The data source is non-recursive, so service names must live directly under the path prefix. If you nest them, set recursive = true or they will be silently excluded.
The for expression maps each parameter’s trailing path segment, the service name, to its value. A new service appears in the map automatically when it writes its first version to SSM. There is no list of service names to maintain.
The companion repository uses a single Terraform root at infra/main.tf for all infrastructure. The version registry module call goes at the top, before any resources that need a version reference.
module “version_registry” {
source = “./modules/version-registry”
ssm_path = “/app/${var.environment}/versions/”
}
locals {
api_version = lookup(module.version_registry.version_map, “api”, “SEED_REQUIRED”)
processor_version = lookup(module.version_registry.version_map, “processor”, “SEED_REQUIRED”)
}
The lookup function provides a fallback for the initial setup, before the application CI has written anything to SSM. The SEED_REQUIRED sentinel makes the unsatisfied state obvious. Resources that depend on these locals will fail at apply time with an AWS error pointing at the missing version. The companion repo’s README walks through the full bootstrap sequence, including pushing an initial image to ECR, writing the first SSM parameters, and running the first apply.
The ECS task definition replaces its hardcoded image tag with the local:
resource “aws_ecs_task_definition” “api” {
# …
container_definitions = jsonencode([{
name = “api”
image = “${aws_ecr_repository.api.repository_url}:${local.api_version}”
# …
}])
}
The Lambda module uses the same pattern for its S3 deployment package key:
module “processor” {
source = “terraform-aws-modules/lambda/aws”
version = “7.4.0”
# …
s3_existing_package = {
bucket = module.lambda_packages_bucket.s3_bucket_id
key = local.processor_version
}
}
In both cases, the version comes from SSM at apply time. If the application CI deployed api:def456 ten minutes ago and wrote that SHA to SSM, the next terraform apply will compute the task definition with api:def456 and leave the latest deployed version untouched.
The sample repository pins the ECS cluster module and the Lambda module to specific versions from the Terraform Registry rather than using raw aws_ecs_* resources, specifically to preserve the module-upgrade scenario as a realistic trigger for version drift.
module “ecs_cluster” {
source = “terraform-aws-modules/ecs/aws”
version = “5.11.4”
# …
}
module “processor” {
source = “terraform-aws-modules/lambda/aws”
version = “7.4.0”
# …
}
This is not incidental. In a production infrastructure repository, module versions are upgraded on a deliberate schedule to pick up security fixes, new features, or provider compatibility updates. Those upgrades are a routine trigger for terraform apply. Without the SSM registry in place, they also carry the risk of silently resetting application versions.
With the registry, a module version bump generates a plan showing only the module changes. The application versions are read live from SSM, match what is running, and produce no diff. That is the before and after in practice.
This sample uses a single environment. In production, the pattern extends cleanly across as many AWS accounts or environments as you need by scoping the SSM path per environment.
Promoting a version from dev to staging is a deliberate act. You write the validated SHA to the staging SSM path and let the staging infrastructure pipeline pick it up on its next apply. It is not an automatic consequence of a push. That deliberate gate is the right model for environment promotion, and the SSM path scoping enforces it naturally.
Part 1 covered the infrastructure side of the pattern. The version registry module reads deployed versions from SSM at apply time. Infrastructure resources reference those live values instead of hardcoded versions. Module upgrades, configuration changes, and routine infrastructure applies can no longer reset a running application to an old version.
Part 2 covers the other side. It walks through the GitHub Actions workflows that write to SSM on every application deployment, how the infrastructure pipeline pre-refreshes the version registry before running, and the operational details that matter in practice. That includes state management, what the plan output looks like on first apply, and how rollback works when you need it.
Disclaimer: The code samples and architecture described in this post are drawn from a public sample repository at github.com/sms-data-products/blog-terraform-ssm-version-registry, built to illustrate the pattern. They do not represent Gridline‘s actual production configuration.
Gridline is a turnkey private markets platform built to set a new standard for how RIAs operate, manage, and scale alternatives.
We partner with RIAs to make private markets operate as simply as public markets.
Our portfolio management capability gives advisors real-time visibility across every client and every investment, so you’re not waiting on quarter-end reports to understand exposures, performance, or cash flow dynamics. You can drill down by client, fund, or strategy to see the full picture, strengthen transparency, and make faster, better-informed decisions with confidence.
Because the data is always current, meeting prep shrinks and client conversations elevate. Reports are ready when you are. They are clear, accurate, and easy to share, turning portfolio complexity into insight clients can trust.
Where most solutions layer tools on top of fragmented workflows, Gridline is built as core infrastructure: one system that runs the full private markets lifecycle. Gridline centralizes every commitment, capital call, valuation, distribution, and document into a single, always-on source of truth, replacing spreadsheets, portals, and PDFs with an always-on, always-up-to-date source of truth that’s available the moment you need it.
The result is a competitive edge that helps you scale, differentiate your firm, and deliver a modern client experience.
This is what it means to set a new standard for alternative investing.
Book a call to see how Gridline helps you scale alternatives without scaling complexity.
Christopher Jones is a Senior Software Engineer at Gridline specializing in resilient, high-performance back-end systems for the financial industry. Since transitioning into software engineering in 2020, he has focused on building reliable, scalable software and infrastructure for mission-critical environments. He developed deep expertise in Infrastructure as Code by creating engineering patterns that improve operational reliability, consistency, and long-term maintainability.
Rob Stewart has over 25 years of experience driving technology innovation. As a cloud architect at SMS, he spearheads the design and implementation of cutting-edge cloud solutions for government and private sector customers, unlocking efficiency and scalability. Prior to SMS, Rob led a global team developing a learning management platform deployed on AWS and was instrumental in driving the adoption of modern devops practices resulting in a dramatic increase in the consistency of software delivery. He is an accredited expert in cloud technologies, with multiple AWS, Azure and Kubernetes certifications. In his free time, he enjoys spending time with his family and two cats.
Over the course of this year, we’ve added a variety of new features to the Gridline platform as we continue on our mission to add efficiency and transparency to private market investing. Here are just a few of our favorites:
See all of the individual companies that your dollars are invested in. Haven’t invested yet? You can still see all portfolio companies across the funds currently and previously available on the Gridline platform.
Quickly and easily create and invest from a self-directed IRA with our integration to Equity Trust. You can both open and fund your account straight from the Gridline platform, either before investing or while creating your investment.
See a comprehensive list of all fund managers that Gridline is working with, including those previously listed for investing. This view allows you to explore the full catalog of opportunities, including managers who are only available in our Portfolio products or managers who may not be in the market currently but are likely to come back onto the platform with their next fundraiser.
Understanding pacing and commitments across an entire portfolio can be challenging, but soon, you’ll be able to visualize commitments, cash flow, and projected portfolio growth with our new Allocation Simulator.
Gridline’s turnkey solution provides a range of features designed to simplify the launch and management of your own custom fund. From KYC to K-1, we provide a superior investing experience for you and your clients.
Book a time to speak with a member of our team to learn more, or sign up in minutes to gain access to the platform.
The private equity industry is around half a century old, while buyouts are as old as capitalism. Today, alternative investments have become an essential part of the portfolio for many institutional investors.
Many investors stick to old-fashioned paper-based processes when making these types of investments. For both investors and RIAs, however, there are many benefits to be gained by digitizing the process.
Gridline’s innovative platform overcomes many legacy challenges of investing in alternatives by digitizing the process, including discovery, subscription, administration, and reporting. The platform provides access to a curated list of investment opportunities and reduces the administrative burden associated with investing in alternatives.
Private equity funds have a long road to closing, with numerous forms and documents that have to be completed. Fundraising and closing include marketing the fund, term negotiation, initial closing, and additional closings.
For investors, too, the process is often manual and paper-based, requiring the completion of multiple forms. This can be a time-consuming process.
With Gridline’s platform, investors can complete their profile once, using it across all investments. This includes auto-populated subscription agreements and digital signing. This makes it easier and faster to close an investment.
As an Institutional Investor report puts it, “private equity is notoriously opaque.”
This can make it difficult for investors to keep track of their investments and performance. Tax management is another complex area that is constantly changing. New proposals would bring about surtaxes for wealthy individuals, changes to the taxation of carried interests, changes to net investment income tax, and more.
With Gridline’s platform, investments are centralized in a unified dashboard. This provides investors with accurate performance reporting and treasury and tax management over the fund’s lifecycle. For RIAs, the native Gridline reporting platform provides a clean, templatized view of your clients’ funded and unfunded commitments, asset class allocations, and their investment value (NAV) at any given time. This is easily distributable to your clients.
Fund administration is a complex and time-consuming task. A veritable alphabet soup of regulatory agencies has a say in how funds are offered, from the SEC to FINRA to the CFTC. Then there are the compliance requirements, which can be onerous.
Gridline’s platform considers all of this and provides a complete fund administration platform that includes KYC and AML checks, which are legally required for most financial institutions. The platform’s payment facilitation includes unique account numbers that automatically track the transfer’s processing status, post a ledger entry when the transfer settles, and reconcile account balances.
In addition, Gridline’s platform implements double-entry accounting for each investment and creates a capital account balance upon signing the investment. The system leverages a tree-based hierarchy whereby each investor has their ledger with account balances automatically aggregated up to the total funds capital account. This makes it easy for investors to see their investment value (NAV) at any time.
Gridline’s platform provides many benefits for both investors and RIAs when it comes to alternative investments. The platform makes it easier and faster to close an investment, provides accurate performance reporting, simplifies fund administration, and more.
While old-school processes may have been enough in the past, today’s investors need a more modern solution that can keep up with the pace of change. Gridline’s platform is designed for the future of investing.
Investors can now allocate retirement assets to top-performing private market funds through Gridline multi-manager portfolio vehicles, the most efficient mechanism for achieving diversification in the alternatives market.
Through a partnership with Millennium Trust Company, Gridline can increase retirement portfolio diversification and reduce portfolio risk by expanding allocations to alternative assets, including Buyout and Venture Capital, asset classes that have historically outperformed public markets.
Today, most Employee Retirement Income Security Act (ERISA) money is effectively going into passive ETF strategies deployed across the public equity and fixed income marketplace. This drives a constant bid into historically over-inflated public markets, with asset values fueled by a long-term low-interest bull market run and a rise in corporate buybacks of stock.
Over-concentrating a retirement portfolio with any one asset class, sector, or region exposes investors to greater market volatility and the potential for larger losses. Individuals nearing retirement age are especially vulnerable to market downturns, as they have less time to recoup their losses.
Actively managed private equity funds align with the strategy of retirement investing. They have historically higher returns than public markets. VC fund of funds have consistently outperformed the S&P 500 and Russell 2000 PMEs, and private equity funds generated an extra 83 cents per dollar invested compared to the public markets.
Sophisticated endowments and family offices have outperformed traditional benchmarks for decades by augmenting portfolios with access-constrained alternative assets. The advantage these institutional investors have over Main Street investors is a long-term view of investing.
Private market investments often come with a lock-up period of up to ten to twelve years, though disbursements can begin as early as year five or six. Retirement funds are already inherently illiquid, so benefit from expansion to asset classes that include an illiquidity premium – the higher return investors expect to earn for an illiquid asset.
The longer time horizon of retirement investing combined with the power of compounding enables retirement investors to build outperforming, diversified portfolios of best-in-class alternative fund managers, supported by Gridline’s institutional-quality selection and diligence process.
In the private equity and venture capital industries, due diligence is essential to uncovering the highest quality managers and reducing risk. After all, the top-quartile managers return more than 22% annualized returns, while the bottom-quartile barely beat inflation.
But with more than 18,000 private equity funds, it can be tough to know where to start. A few tangible principles can help guide the way, including people, performance, philosophy, and process. Four less tangible principles can also play a role in manager selection: passion, perspective, purpose, and progress.
Among various other elements, Gridline’s due diligence process focuses on these “four P’s” to identify the best possible managers for our clients. We make access to these managers available via Thematic Portfolios for a targeted investment thesis or vehicle that provides access to funds typically reserved for insiders.
When it comes to people, we want to know about the quality, depth, and experience of the fund’s investment team.
The team’s pedigree is important, but so is diversity. Studies show that diverse PE funds outperform their non-diverse counterparts. Additionally, relying solely on a star manager can be dangerous, so we also want to see a deep bench of talent. After all, emerging managers outperform established managers.
Key measures when it comes to performance include internal rate of return (IRR), multiple of invested capital (MOIC), and public market equivalent (PME).
IRR is a capital-weighted return providing a single cumulative figure that is useful for comparing different sizes and durations of investments. Unlike IRR, which measures the “when” of the return, MOIC measures the “how much” by dividing total proceeds by total capital invested. This is a key ratio for understanding how much value a manager has created.
PME compares private capital fund performance to public indices and is a useful metric for understanding whether a manager is truly adding value or if they are simply riding the wave of a bull market.
Value-creation is the primary focus of private capital, so it’s important to align with a manager who shares that philosophy. A long-term orientation toward investments and a willingness to actively work with portfolio companies are key.
Exploiting market inefficiencies is another key part of the private capital investment philosophy, so we also look for managers who deeply understand their chosen market or industry. This allows them to identify opportunities that others may miss.
A manager’s investment process should be clear, repeatable, and well-documented. A disciplined approach to research and decision-making, as well as a focus on continuous improvement, is vital.
Additionally, it’s important to know how positions or themes are added to the portfolio, monitored, and removed. A good investment process will help ensure that the portfolio is well-constructed and managed to minimize risk.
In addition to the four key principles of people, performance, philosophy, and process, four intangible factors can also play a role in manager selection: passion, perspective, purpose, and progress.
Passionate managers are those who are truly dedicated to their work and have a genuine interest in making a difference. They should also be able to articulate their vision for the future and inspire others to buy into it. Diversity of perspective is also important to avoid groupthink and generate new ideas. That’s why we look for open-minded managers embracing diverse views.
Private capital managers should have a clear purpose beyond simply making money. They should be motivated by creating value and positively impacting the world. Finally, we want to see evidence of progress.
Gridline’s due diligence process includes these “four P’s” to identify the best possible managers for our clients. This allows our clients to invest confidently, knowing they are aligned with some of the top talents in the industry.
John Bogle, the founder of Vanguard, has been called “the father of indexing.” In 1976, he launched the Vanguard 500 Index Fund, which tracked the performance of the Standard & Poor’s 500 Index.
This was a revolutionary idea at the time. Before this, most investors only had access to mutual funds that fund managers actively managed. These funds typically came with high fees and didn’t always perform as well as their benchmark indices.
Bogle realized he could offer investors a low-cost way to get diversified exposure to the equity market. With the launch of the Vanguard 500 Index Fund, Bogle disrupted the mutual fund industry. He showed that offering investors a better product at a lower cost was possible. And in doing so, he helped make investing more accessible for everyone.
Today, Vanguard is one of the largest asset managers in the world, with over $7 trillion in assets under management. The company offers various products, including index and exchange-traded funds (ETFs).
Economists admit that the rampant inflation of the past year isn’t transitory, and it’s possible we haven’t seen the worst. This has renewed a flight to private markets where investors seek assets that can protect their purchasing power and generate real returns.
But it’s not just inflation driving this move into private markets. Even with interest rates rising from historically low levels, they still provide extremely low returns. This means that investors are searching for yield in other places.
Private equity, real estate, and other illiquid assets have historically outperformed public markets. For example, over the past two decades, annual leveraged buyout returns outpaced global equities by more than 10 percent on average.
Institutional investors have been allocating more of their portfolios to private markets in recent years as they seek higher returns. As individual investors become more sophisticated, they’re also starting to allocate more of their assets to alternatives.
However, investing in private markets has traditionally been difficult for individuals. The process is often convoluted and time-consuming. And because these assets are not traded on public exchanges, they can be difficult to value.
Moreover, minimum contributions for private equity and real estate funds can be quite high. For example, some private equity funds have minimums of $25 million or more. This effectively shuts out many individual investors from these types of opportunities. Further, considering the importance of diversifying across funds, these high minimums limit an investor’s ability to build a diversified portfolio.
Gridline was founded to make alternative investments more accessible for everyone. The company has created a platform that allows investors to discover, track, and invest in private equity, venture capital, and other alternative assets.
Gridline has also digitized the process, from sourcing deals to investment committee approval. This streamlines the process and makes it much easier for potential investors to get involved.
But perhaps most importantly, Gridline has lowered the minimum contribution requirements for many of its funds. This enables a wider range of investors to access these assets. And because Gridline offers a diverse selection of funds, investors can build a well-diversified portfolio without committing a large amount of capital.
In many ways, Gridline is following in Vanguard’s footsteps. Like Vanguard, Gridline is focused on making investing more accessible for everyone. And by offering a better product at a lower cost, Gridline is changing the investing landscape.
Try out Gridline today and see how easy investing in private markets can be.
Alternative investments, like venture capital and private equity, have been around for decades. But the process for investing in these assets is still incredibly antiquated.
The first step, sourcing deals, is often done through personal relationships and networking. Once a potential deal is found, a non-disclosure agreement (NDA) must be signed to access the investment materials. Then, the due diligence process begins.
This is where things can get really cumbersome. Potential investors must fax over their subscription agreement and personal information to the fund manager. A first-round bid or non-binding term sheet is then drafted and sent back to the potential investor.
Once further due diligence is completed and both parties are happy with the deal, a preliminary investment memorandum (PIM) is sent out. If the potential investor wants to move forward, they must then engage a lawyer to review the PIM.
The final step is investment committee approval, after which wire instructions are sent out to the investor. The entire process is still done manually and is incredibly time-consuming. It’s not uncommon for the whole process to take months or even years.
But things are finally changing. A number of startups are working on making the alternative investment process more efficient and modern. Gridline has developed an online platform that allows investors to access alternative investments, including private equity, with a few clicks.
While it will still take some time for the industry to catch up, it’s clear that the days of faxing over subscription agreements and personal information are numbered.
The legacy approach to alternative investing is cumbersome, time-consuming, and outdated, which limits many individuals’ ability to access these types of assets.
Gridline has developed an online platform that makes it easy for investors to discover, track and invest in alternative assets. The platform is simple and intuitive and allows investors to quickly register and deploy capital.
Gridline has also digitized the entire process, from sourcing deals to investment committee approval. This streamlines the process and makes it much easier for potential investors to get involved.
The future of alternative investing is digital, efficient, and open to everyone. With Gridline, gone are the days of faxing over documents and waiting months for a deal to go through.
We’ve written about the many benefits of alternative investments, but one of the biggest is the potential for high returns. Private markets have significantly outperformed public markets for the past two decades, and investors are taking notice. In 2021, global private equity fundraising hit a record $733 billion, and 2022 is on pace to exceed that.
Institutional investors are allocating more of their portfolios to private equity, real estate, and other illiquid assets as they chase higher returns. And it’s not just pension funds and endowments; even insurance companies and sovereign wealth funds are getting in on the action. Not only that, but alternative assets like venture capital have a low correlation to traditional asset classes, providing much-needed diversification.
In a world with rampant inflation, low-interest rates, and political uncertainty, alternative investments offer a unique opportunity to generate real returns. So it’s no wonder that they’re becoming more popular every day.
However, accessing these types of investments has been difficult, if not impossible, for many individuals. This is where Gridline comes in. By making alternative investing more efficient and accessible, we’re opening up these types of assets to a wider range of investors.
This democratization of access to alternative investments has the potential to change the landscape of investing, and we’re excited to be at the forefront of this shift.
If you are considering investing in the private markets, your options to access alternatives are either SPV’s and rolling funds or actively managed funds.
SPVs and rolling funds make money even if the underlying investments aren’t successful, so they often focus on access to deals, and not on ensuring the underlying investments have a positive outcome once capital is deployed.
Our focus at Gridline is on top-quartile, actively managed funds with highly involved fund managers and general partners. Traditionally this kind of financial product can become expensive, with layers of fees offsetting their gains. Gridline’s fee structure allows investors to keep more of the returns in their own pockets.
A traditional fund of funds typically layers at least a 1% management fee and 10% carry on top of the underlying fund’s 2% and 20% fee.
Banks and wirehouses often add yet another wealth management or advisory fee on top, resulting in a 20% to 30% total cost over the life of the investment. There’s too many fingers in the cookie jar for the investor to win in the end.
At Gridline, we charge a simple, AUM-only fee with a tiered structure, much like you’d see from a mid-size RIA. We charge 50 to 100 basis points decreasing based on their total AUM with Gridline. Our fund investments have zero carried interest which ultimately helps us generate better net returns for our users.
When you look around at the universe of investment opportunities, it becomes clear that private markets are broken.
The market for alternatives — things like venture capital, private equity, real estate and crypto — is booming, with more than $5 trillion expected to come into this market over the next four years. It’s further proof that the traditional 60/40 portfolio allocation model doesn’t work anymore with yields low and public equities hitting all-time highs. Generating the returns investors are used to requires taking on more risk, driving all this attention in alternative asset classes.
But there’s one problem.
While public markets are more accessible than ever — with social media and fee-free trades attracting a whole new generation of investors — private markets remain closed off, even to high net worth individuals. Supply and demand is concentrated among a select group of insiders.
We built Gridline to solve these persistent inefficiencies. We want to help individuals invest like the most successful endowments and family offices that are using alternative investments to generate excess returns. Big endowments like Yale put as much as 60% of their portfolio in alternatives and are reaping the benefits as a result of having exposure to diversified, non-correlated assets.
The problem isn’t just on the investor side. Emerging and even established fund managers are spending weeks and months — as much as a third of the time they’re raising capital — just identifying potential investors. Even the largest global funds struggle with how to bring retail investors into the fold and diversify the contribution base.
Those investors are out there, but they’re stuck on the sidelines waiting for an invite.
What alternatives have been clamoring for is a matchmaker, that connective tissue that brings investors who aren’t experiencing the returns they want and alternative asset managers who need a bigger audience together in a unified marketplace. Gridline achieves this by providing access to an expertly curated set of funds while leveraging technology to streamline the often cumbersome process of investing in alternatives.
We’re strong believers in the power of actively managed funds. The alternative investment landscape has seen a lot of focus on investments in individual companies or things like one-off real estate deals. But we’ve worked with great advisors and capital allocators and know the added value they can bring in turning a good company into a great business over time.
That’s why we’re starting with venture capital funds that we’ve picked based on a comprehensive selection criteria, with a bent toward managers with results verified by empirical evidence and a vested ownership in their funds’ success. These are not people spinning up an SPV to capture the upside with none of the downside risk — their livelihood depends on the success of the total fund and their investors get that benefit. Our users will be able to access these funds — which traditionally required as much as $1 million in liquidity — with minimums as low as $100,000. We’re keeping our fees low, charging an AUM fee that ranges from 0.5%-1.0% on invested capital.
The financial products themselves are only part of the problem we’re addressing. We’re also building industry-leading technology to improve the “rails” that make investing in these asset classes challenging. We’ve seen this kind of transformation in areas where offline, manual financial processes have been replaced by fintech applications in payments, lending and other banking services.
In alternatives, there’s a lot of messy back-end processes like investor questionnaires, KYC, treasury management, capital calls and tax reporting that can all be done digitally. We’re automating and leveraging technology to make that part as easy as executing a trade in the public markets online.
Tackling both sets of challenges I’ve described opens up private markets to a whole new set of investors. Investing in these asset classes today is out of reach for far too many and we’re excited to be building a future where everyone can have access to endowment-style investing and reap the superior returns it offers.
Put simply, we are building a platform that enables individual investors to emulate what the smartest investors in the world are doing with their portfolios. Our platform provides individuals the ability to discover and build a highly diversified alternative asset portfolio while concurrently expanding the pool of investors funds can leverage … we hope you join us on this journey.