Iconik + StorNext Ingest: Automate It Without the ISG
StorNext gives your media operation the performance and shared access it needs.
Iconik gives your team the search, metadata, and collaboration layer it expects.
Together, they make a powerful foundation for modern media asset management.
But there is usually a gap between the two.
That gap is ingest.
And when the workflow depends on an Iconik Storage Gateway : plus shell scripts, manual checks, and one person who knows how everything fits together : the infrastructure becomes harder to operate than it needs to be.
IngestR replaces that fragile ingest layer with a repeatable workflow that runs on your hardware.
Watch folders. Transcode and proxy. Metadata mapping. Iconik registration. Archive ingest and verification.
No babysitting required.
StorNext for storage. Iconik for search.
The Iconik and StorNext pairing makes sense because each platform solves a different problem.
Quantum StorNext provides high-performance shared storage for production media. Your editors, operators, and systems can work with large camera originals and project files without forcing every asset into the cloud.
Iconik, meanwhile, provides the media asset management layer. It helps teams search, organize, preview, collaborate around, and manage media across locations and storage environments.
That separation is valuable.
Your high-resolution originals can stay on-premises. Your team can still use Iconik to find assets and work with lightweight proxies. Your archive can follow policies appropriate for the organization, the production, and the media itself.
But the systems need a reliable connection.
A file landing on StorNext is not automatically a complete media asset in Iconik.
Someone : or something : still needs to:
- Detect that the file arrived
- Confirm the write is complete
- Generate a usable proxy
- Extract or map metadata
- Register the asset correctly in Iconik
- Associate the right format components and keyframes
- Confirm the result is complete and playable
- Move or copy the original into its intended archive path
That is the ingest layer.
And it is where many operations start accumulating workarounds.
The gap in the middle
The Iconik Storage Gateway can help bridge Iconik and on-premises storage. In a straightforward setup, it monitors directories and indexes files in place so Iconik can represent media that remains on local infrastructure.
That is useful for certain workflows.
But indexing files is not the same as orchestrating the full ingest lifecycle.
The difference becomes obvious when your operation handles camera cards, delivery drives, multiple formats, proxy requirements, metadata standards, and archive policies at the same time.
The ingest workflow often turns into a collection of supporting pieces:
- A watch-folder script
- A transcode command
- A proxy-generation profile
- A metadata sidecar process
- A registration step
- A copy or archive script
- A verification check
- A spreadsheet, log, or message confirming what happened
Each piece may work on its own.
The problem is the handoff between them.
A network share drops. A credential changes. A file is still being written when the process starts. A transcode completes but the Iconik registration fails. An archive copy finishes without anyone confirming that the result can be restored.
Then the workflow stops.
Or worse : it appears to finish.
Someone has to investigate. Someone has to rerun the failed step. Someone has to remember which files already completed.
That person is usually an editor, assistant editor, media manager, or systems administrator.
None of those roles should be spending the day babysitting ingest.
What a proper ingest layer looks like
A reliable media asset management integration gives every system a clear role : and gives the workflow a clear sequence.
1. Watch for complete media
IngestR can monitor a watch folder, mounted card, or delivery path on your infrastructure.
It detects new media, waits for writes to settle, and queues the job. Before processing begins, preflight checks validate configuration, credentials, mount points, and target availability.
That matters.
A bad credential should surface at startup : not after several hours of processing.
2. Process media in parallel
Once a job is ready, IngestR orchestrates transcodes, proxy generation, and keyframe extraction through FFmpeg-based workflows.
Profiles define what should be created and how it should be created.
Jobs can run across available CPU and GPU resources instead of forcing a full camera card to process one file at a time.
The result is a faster path from acquisition to editorial access.
Editors do not need the camera original to begin reviewing and cutting. They need a dependable proxy, correctly associated with the asset they can find in Iconik.
3. Map metadata before registration
Metadata is most useful when it arrives with the asset.
IngestR maps the metadata you define during ingest and registers assets in Iconik with the appropriate format components, proxies, keyframes, spritesheet maps, and associations.
That means fewer placeholder records.
Fewer cleanup passes.
Less backfilling after the production team has already moved on.
This is one of the most important differences between a simple file index and a true ingest automation workflow.
4. Register directly in Iconik
IngestR uses Iconik’s native REST integration to create and update asset records as part of the ingest process.
The original media can remain on StorNext or another approved local storage target. Iconik receives the searchable asset record and the media components required for review and collaboration.
Your team gets a connected workflow without forcing your entire media library through a new storage model.
5. Verify the archive
Archive is not complete because a copy command returned successfully.
A proper workflow verifies that the asset landed completely and remains playable.
IngestR tracks job state in a local database and uses webhook-driven validation to confirm the result. If a run is interrupted, it can resume from the last completed step instead of restarting from the beginning.
Every job leaves an auditable record.
That gives your team an answer when someone asks, “Did that ingest actually finish?”
An ISG replacement for the workflows that need more control
Calling IngestR an ISG replacement does not mean every Iconik and StorNext environment must remove the Iconik Storage Gateway.
Some teams may continue using ISG to index broader storage areas or existing media in place.
The point is more practical:
For controlled, high-volume ingest, IngestR replaces the need to make ISG carry the entire workflow.
It handles the steps that happen before and after basic file discovery:
- Ingest automation from cards, watch folders, and delivery drives
- Transcode and proxy generation
- Metadata mapping
- Iconik registration
- Keyframe and format-component association
- Archive-aware movement
- Validation and resumable job tracking
That gives you a deliberate ingest path instead of a loose connection between storage and MAM.
And it lets your team decide where each asset belongs, what derivatives should exist, and what must be verified before the job is considered complete.
The result: editors create instead of troubleshoot
When the workflow is designed correctly, the benefits show up in the daily operation.
🔄 Editors get proxies faster.
They can begin reviewing and cutting while originals stay protected on your storage infrastructure.
🧩 Iconik records arrive with useful context.
Metadata, format components, proxies, and keyframes are populated during ingest : not weeks later.
🔒 Archive copies are verified.
Your operation has a record of what completed and what needs attention.
⚡ Failures are recoverable.
A network interruption does not have to erase hours of completed work.
🛠️ The process is supportable.
Workflows are defined in configuration rather than scattered across undocumented scripts.
🎯 No one owns the shell scripts.
The workflow belongs to the operation, not the person who happened to build it.
IngestR has already supported workflows with 100s of thousands of assets ingested in weeks and 90% fewer manual touchpoints.
Those numbers matter because ingest is not an isolated technical task. It affects editorial speed, archive confidence, metadata quality, and the amount of operational attention your team has available for higher-value work.
Built around your existing infrastructure
IngestR runs on your infrastructure : bare metal or virtualized : so your media can stay within your environment.
It is designed to work with:
- Iconik
- Quantum StorNext
- Standard SMB and NFS shares
- StorNext Storage Manager
- FFmpeg-based media workflows
- CPU and GPU processing
- Your existing archive and operational policies
That makes it a practical fit for broadcast, live production, university athletics, post-production, corporate video, and other teams where every camera brings a deadline.
Your environment does not need to look like anyone else’s.
That is the point.
1303 Systems scopes each deployment against your storage, MAM, archive topology, and workflow requirements. The result is not another generic automation product to configure alone. It is an ingest layer shaped around how your team actually works.
Frequently asked questions
Does IngestR replace Iconik?
No. IngestR feeds Iconik. It is the automation layer between acquisition, storage, MAM registration, and archive.
Does IngestR replace the Iconik Storage Gateway?
It can replace ISG for controlled ingest workflows that require transcode, proxy generation, metadata mapping, registration, and verification. ISG may still be useful for indexing other storage areas.
Where does IngestR run?
IngestR runs on your infrastructure, either on bare metal or in a virtual machine environment.
Do we need GPUs?
No. GPUs are not required. They can improve processing performance when available, while CPU processing remains supported.
What happens when an ingest fails?
The failure is logged with its cause. When the job restarts, IngestR resumes from the last completed step rather than silently starting over.
Can IngestR work with our existing StorNext and archive setup?
Yes. IngestR is designed for Quantum StorNext, standard SMB/NFS shares, and StorNext Storage Manager policy targets. Other environments can be evaluated during workflow scoping.
Stop babysitting the ingest layer
You already invested in storage.
You already invested in your MAM.
Now connect them with an ingest workflow that can do more than watch a folder and hope for the best.
Explore IngestR to see how your team can automate the path from media acquisition to Iconik registration and verified archive.
Or contact 1303 Systems for a walkthrough built around your current Iconik, StorNext, and archive environment.
The goal is simple:
Get footage into your MAM without babysitting it.