Oracle Cloud Using Marketplace Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Marketplace

1. Introduction

Oracle Cloud Using Marketplace is the practical workflow of discovering, evaluating, subscribing to, and deploying third‑party (and Oracle‑published) solutions from Oracle Cloud Marketplace into your Oracle Cloud tenancy.

In simple terms: Marketplace is a catalog of ready-to-deploy software and cloud solutions. Using Marketplace means you can launch curated VM images, deploy Terraform/Resource Manager stacks, or subscribe to SaaS offers without building everything from scratch.

Technically, Oracle Cloud Marketplace integrates with core Oracle Cloud Infrastructure (OCI) services such as Compute, Networking (VCN), and Resource Manager. Marketplace listings include publisher-provided artifacts (images, stacks, SaaS links), pricing/terms, and deployment instructions; when you deploy, the underlying OCI services create resources in your compartments using your IAM permissions.

The problem it solves: teams waste time and introduce risk when they manually assemble common infrastructure/software patterns. Using Marketplace accelerates deployments, standardizes acquisition and licensing, and provides a governed path to deploy vendor solutions—while keeping deployment within your tenancy and IAM controls.

2. What is Using Marketplace?

Using Marketplace (in Oracle Cloud, under the Marketplace category) is the end-to-end process of:

Browsing and searching Marketplace listings
Reviewing publisher details, documentation, and support
Accepting terms and (if applicable) subscribing to paid usage or BYOL licensing
Deploying a solution into your tenancy (for images/stacks) or activating an external SaaS subscription
Managing the lifecycle (updates, scaling, monitoring, security posture, and cost) using OCI services

Official purpose (service scope)

Oracle Cloud Marketplace’s purpose is to provide a catalog of partner and Oracle solutions that can be deployed or subscribed to, with clear terms and (where applicable) integrated billing.

Verify the most current Marketplace overview and “Using Marketplace” documentation in official docs:
https://docs.oracle.com/en-us/iaas/Content/Marketplace/home.htm

Core capabilities

Discovery & evaluation: search, filter, compare solutions; review documentation and support information.
Subscription & governance: accept terms, track subscriptions/offers, and align to procurement processes.
Deployment: deploy supported listing types (commonly VM images and Resource Manager stacks) into OCI resources you control.
Billing integration (when applicable): some listings bill via OCI usage; others are BYOL or external billing.
Operational integration: deployed resources are managed using standard OCI primitives (instances, VCNs, load balancers, etc.).

Major components

Marketplace Console experience: where you search listings, review details, and initiate deployment.
Listings: the catalog entries (each with publisher info, pricing model, and deployment artifacts).
Agreements/terms acceptance: required before deployment/subscription.
Deployment artifacts (by listing type):
Images (VM images that run on OCI Compute)
Stacks (often Terraform configurations deployable via OCI Resource Manager)
SaaS / services (subscription workflows that may redirect to publisher systems)

Service type

Marketplace is primarily a catalog + subscription + deployment integration layer, not a standalone runtime like Compute or Storage. The actual runtime is provided by underlying OCI services.

Scope: regional/global/tenancy

Marketplace catalog access is available through the Oracle Cloud Console (availability depends on tenancy configuration and region; verify in official docs).
Deployments are region-bound because resources like Compute instances, VCNs, and load balancers are created in a specific OCI region.
Subscriptions/agreements are typically tenancy-scoped (and may have region-specific constraints depending on the listing). Always read the listing terms.

How it fits into the Oracle Cloud ecosystem

Using Marketplace sits at the “front door” of solution acquisition and deployment, integrating with:

Identity and Access Management (IAM): who can subscribe/deploy
Compartments & tagging: where resources are created and how they’re governed
Compute / VCN / Load Balancer / Block Volumes: typical runtime targets
Resource Manager (Terraform): infrastructure-as-code deployment for stacks
Logging / Monitoring / Audit: operational visibility and governance

3. Why use Using Marketplace?

Business reasons

Faster time-to-value: deploy vetted solutions quickly rather than building everything from scratch.
Procurement alignment: listing terms, licensing approaches (BYOL/metered), and billing integration can simplify purchasing (exact mechanics vary by listing).
Vendor ecosystems: access partner solutions commonly required for enterprise workloads (security, networking, databases, analytics, DevOps tooling).

Technical reasons

Reference architectures “packaged” into deployables: many solutions ship as images or IaC stacks that represent known-good patterns.
Repeatable deployments: stacks reduce “snowflake” infrastructure and increase consistency.
Integration with OCI primitives: deployments create standard OCI resources you can manage with your existing toolchain.

Operational reasons

Standard lifecycle management: once deployed, resources are managed like any OCI resource (patching, backups, scaling).
Support clarity: listings typically define who supports what (publisher vs Oracle vs shared responsibility).
Fewer manual steps: preconfigured images and templates reduce operational toil.

Security/compliance reasons

Governed access: IAM policies and compartments help constrain who can deploy what and where.
Traceability: OCI Audit logs actions such as resource creation and configuration changes.
Reduced supply-chain ambiguity (when used correctly): Marketplace provides publisher identity and a consistent acquisition path. (You still must validate publisher, artifacts, and configurations.)

Scalability/performance reasons

Production-grade patterns: many listings assume scale-out designs and integrate with load balancers, autoscaling, and HA topologies.
Right-size from day one: templates often include sizing guidance (verify each listing).

When teams should choose it

Choose Using Marketplace when: – You need a standard solution quickly (e.g., firewall appliance, CI runner, logging agent, API gateway, CMS, VPN). – You want an IaC-based deployment that your platform team can standardize. – You need commercial software with a defined licensing model and support channel.

When teams should not choose it

Avoid or be cautious when: – You cannot validate the publisher, supportability, or security posture. – The listing forces a licensing model that conflicts with your procurement rules. – Your environment requires very tight hardening and you can’t verify image provenance and update cadence. – You can achieve the same outcome with simpler native services (lower operational burden) or your existing golden images and templates.

4. Where is Using Marketplace used?

Industries

Financial services: security appliances, SIEM connectors, secure access gateways, hardened images
Healthcare: compliance-focused deployments, secure data movement tooling
Retail/eCommerce: CMS, caching layers, WAF/security, observability
Manufacturing/IoT: edge data ingestion tooling, messaging stacks
Public sector: compliant images, vendor-certified solutions (verify certification claims per listing)

Team types

Platform engineering teams standardizing “approved” deployments
DevOps/SRE teams accelerating environment provisioning
Security teams deploying network/security appliances and scanners
Application teams needing packaged runtimes (CMS, API gateways, app servers)
Architects evaluating vendor solutions and integration patterns

Workloads

Security & networking: firewalls, VPN, IDS/IPS, WAF integration components
Observability: logging/monitoring agents, APM components, SIEM forwarding
Dev tooling: CI agents, artifact caching, configuration tooling
Web workloads: WordPress-like stacks, reverse proxies, web servers (listing availability varies)
Data & integration: connectors, ETL tools, message brokers (often via stacks)

Architectures

Single-instance dev/test proofs of concept
Multi-tier production systems (LB + app tier + DB)
Hub-and-spoke networks with security appliances in shared services compartments
IaC-driven landing zones where Marketplace stacks are integrated into pipelines

Production vs dev/test usage

Dev/test: fastest path to a working environment; focus on cost controls and cleanup.
Production: requires governance: IAM, network segmentation, patching strategy, observability, backups, DR, and vendor support plans.

5. Top Use Cases and Scenarios

Below are realistic, OCI-aligned scenarios for Using Marketplace. Availability and exact steps vary by listing—always confirm in the listing documentation.

1) Deploy a vendor security appliance in a DMZ

Problem: Need a next-generation firewall or IDS in front of workloads quickly.
Why Marketplace fits: Vendors provide certified images and deployment guides.
Scenario: Deploy appliance VM(s) into a dedicated VCN subnet, integrate with route tables and NSGs, and steer traffic through it.

2) Launch a prebuilt developer workstation image

Problem: Engineers need consistent toolchains without days of setup.
Why Marketplace fits: Images can ship with curated tooling and versions.
Scenario: Launch a developer VM image, connect via SSH, and use it as a build/test box.

3) Deploy an application via Resource Manager stack (Terraform)

Problem: Manual provisioning is error-prone and inconsistent.
Why Marketplace fits: Stacks encode infrastructure patterns as code.
Scenario: Deploy a stack that creates VCN, compute, and security rules with parameterized inputs.

4) Evaluate a commercial software trial quickly

Problem: Procurement and setup time delays technical evaluation.
Why Marketplace fits: Listings may support trials or quick starts.
Scenario: Subscribe to a listing, deploy into a sandbox compartment, and test against requirements.

5) Standardize “approved” images for regulated environments

Problem: Teams deploy random images that fail audits.
Why Marketplace fits: Centralized catalog with publisher identity and consistent access.
Scenario: Security team approves a hardened image listing; platform team restricts deployments to that image.

6) Deploy a monitoring/agent gateway for hybrid workloads

Problem: Need agent infrastructure to forward logs/metrics from on-prem to OCI.
Why Marketplace fits: Some vendors package gateways/collectors.
Scenario: Deploy a collector VM in a private subnet with outbound access to vendor endpoints or OCI services.

7) Spin up a proof-of-concept web app stack

Problem: Need a working web app quickly for demos.
Why Marketplace fits: Prebuilt stacks can include reverse proxy, app tier, and database integration.
Scenario: Deploy a stack into an Always Free-eligible shape (where possible) and validate functionality.

8) Deploy a data movement or backup connector

Problem: Need consistent backups or data transfer tooling.
Why Marketplace fits: Vendors provide appliances or templates integrated with object storage.
Scenario: Deploy connector, configure Object Storage bucket, schedule transfers.

9) Roll out consistent CI runners in OCI

Problem: CI runners need consistent dependencies and scaling.
Why Marketplace fits: Some listings provide runner images/templates.
Scenario: Deploy runners into a dedicated compartment with autoscaling rules and restricted network egress.

10) Build a reference architecture baseline faster

Problem: Architects need a “known-good” baseline to start projects.
Why Marketplace fits: Marketplace stacks often represent reference architectures.
Scenario: Deploy baseline networking + compute + logging stack, then layer applications.

11) Deploy an API gateway or ingress controller pattern

Problem: Need standardized ingress and routing policies.
Why Marketplace fits: Some solutions ship as stacks/images with documented patterns.
Scenario: Deploy gateway tier behind OCI Load Balancer and integrate with private backends.

12) Create a training lab environment for teams

Problem: Need repeatable labs for onboarding.
Why Marketplace fits: Stacks provide repeatable infrastructure and cleanup.
Scenario: Instructors deploy identical environments per cohort and tear down after training.

6. Core Features

Marketplace features evolve; confirm exact capabilities in current Oracle Cloud docs and the Console.

6.1 Listing discovery (search, categories, filters)

What it does: Helps you find solutions by category, publisher, price model, and other metadata.
Why it matters: Reduces time spent validating random internet images or scripts.
Practical benefit: Faster shortlist creation for architecture decisions.
Caveats: Not every listing is available in every region; availability can vary.

6.2 Listing details: documentation, architecture, and support info

What it does: Provides publisher documentation, deployment guides, support channels, and terms.
Why it matters: Clarifies responsibility boundaries and prerequisites.
Benefit: Better operational planning and fewer “unknowns”.
Caveats: Quality varies by publisher; validate and test.

6.3 Terms acceptance and subscription flow

What it does: Requires users to accept legal terms before deploying/using a listing.
Why it matters: Helps align with licensing and compliance requirements.
Benefit: Traceable governance step.
Caveats: Some organizations require procurement review before acceptance.

6.4 Multiple pricing models (listing-dependent)

What it does: Supports listings that are free, BYOL, or billed based on usage/subscription.
Why it matters: You can align to your budget model and licensing posture.
Benefit: Flexibility.
Caveats: Pricing is listing-specific; do not assume “free” means “no costs” (compute/network still apply).

6.5 Deployment to OCI resources (Images)

What it does: Launches a Compute instance from a publisher image.
Why it matters: Speeds setup of complex software.
Benefit: Reduced manual installation/configuration.
Caveats: You still own patching and hardening unless the listing states otherwise.

6.6 Deployment via OCI Resource Manager (Stacks)

What it does: Uses Terraform-based templates to create multiple OCI resources.
Why it matters: Repeatable, auditable infrastructure.
Benefit: Faster production-like provisioning.
Caveats: Review templates carefully; they may create billable resources and open network paths.

6.7 Integration with compartments and tagging (governance)

What it does: Lets you deploy into specific compartments and apply tags (depending on resource types created).
Why it matters: Cost allocation and policy enforcement.
Benefit: Cleaner operations and chargeback/showback.
Caveats: Tagging discipline is on you; templates may not tag everything by default.

6.8 Auditability via OCI Audit (indirect but critical)

What it does: Actions taken in OCI (creating instances, VCNs, etc.) are captured by Audit.
Why it matters: You need traceability for security investigations and compliance.
Benefit: Forensics and accountability.
Caveats: Ensure Audit is retained and monitored according to your policy.

6.9 Publisher ecosystem and updates (listing-dependent)

What it does: Publishers may update images/stacks over time.
Why it matters: Updates can address vulnerabilities and add features.
Benefit: Better security posture if you stay current.
Caveats: Updates are not automatically applied to your running instances unless you patch/upgrade.

7. Architecture and How It Works

7.1 High-level architecture

At a high level, Using Marketplace involves:

User searches Marketplace in the OCI Console.
User selects a listing, reviews details, and accepts terms.
User chooses deployment method (commonly: launch image to Compute or deploy stack via Resource Manager).
OCI provisions resources in the selected compartment and region.
You operate the deployed resources with standard OCI tools (Console, CLI, SDK, monitoring/logging).

7.2 Request/data/control flow

Control plane: Console/API calls for Marketplace subscription and for provisioning OCI resources.
Data plane: Traffic to/from deployed instances/services in your VCN (e.g., inbound HTTP to a VM, outbound updates to repos).
Billing flow: If listing is paid through OCI, usage records flow into OCI billing; otherwise billing may happen externally (listing-specific).

7.3 Integrations with related services

Common integrations include: – OCI Compute: Marketplace images run as VM instances. – OCI Resource Manager: stacks deploy Terraform-managed infrastructure. – OCI Networking (VCN, subnets, IGW/NAT/Service Gateway): connectivity for instances and applications. – OCI Vault: store secrets (recommended for production). – OCI Logging and Monitoring: collect logs/metrics from deployed components. – OCI Bastion: reduce need for public SSH exposure (recommended).

7.4 Dependency services

Using Marketplace typically depends on: – IAM (users, groups, policies) – Compartments – Target runtime services (Compute, VCN, LB, OKE, etc.) depending on listing type

7.5 Security/authentication model

Users authenticate to OCI using IAM (local users, federation, SSO, etc.).
Authorization is enforced via IAM policies at tenancy/compartment scope.
Deployments inherit the permissions of the user (or group) performing the action.

Exact IAM policy verbs/resources for Marketplace can change; verify the current IAM policy reference in official docs.

7.6 Networking model

Marketplace itself is a control-plane experience.
Deployed resources live inside your VCN and follow your network design:
Public subnets + Internet Gateway for public endpoints (use cautiously)
Private subnets + NAT/Service Gateway for controlled egress
NSGs/Security Lists to constrain flows

7.7 Monitoring/logging/governance

Use OCI Monitoring for metrics and alarms.
Use OCI Logging for OS/app logs (agent-based if needed).
Use OCI Audit to track provisioning and configuration actions.
Use tags (cost-tracking and governance) and budgets where applicable.

Simple architecture diagram (Mermaid)

flowchart LR
  U[Engineer / Admin] --> C[OCI Console]
  C --> M[Oracle Cloud Marketplace]
  M -->|Launch Image / Deploy Stack| P[OCI Provisioning APIs]
  P --> CMP[Compute Instance]
  P --> NET[VCN/Subnet/NSG]
  CMP --> APP[Installed Marketplace Software]

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph Identity
    IDP[Enterprise IdP / Federation]
    IAM[OCI IAM]
    IDP --> IAM
  end

  subgraph Governance
    CMPA[Compartments]
    TAG[Tags & Tag Defaults]
    AUD[OCI Audit]
  end

  subgraph Marketplace
    MKTP[OCI Marketplace Listing]
    TERMS[Terms / Subscription]
    MKTP --> TERMS
  end

  subgraph Deployment
    RM[OCI Resource Manager (Terraform)]
    VCN[VCN]
    PUB[Public Subnet]
    PRI[Private Subnet]
    LB[Load Balancer]
    APP1[App VM(s) from Marketplace Image]
    BAST[OCI Bastion]
    VAULT[OCI Vault]
    LOG[OCI Logging]
    MON[OCI Monitoring]
  end

  IAM --> MKTP
  IAM --> RM
  TERMS --> RM

  RM --> VCN
  VCN --> PUB
  VCN --> PRI
  RM --> LB
  RM --> APP1
  RM --> BAST
  RM --> VAULT

  LB --> APP1
  BAST --> APP1
  APP1 --> LOG
  APP1 --> MON

  AUD --> RM
  CMPA --> RM
  TAG --> RM

8. Prerequisites

Tenancy and account requirements

An active Oracle Cloud (OCI) tenancy
Ability to access Marketplace in the OCI Console
A target region where you will deploy resources

Permissions / IAM

You typically need permission to: – View and subscribe/accept terms for Marketplace listings – Create and manage required OCI resources (commonly: Compute, VCN, subnets, NSGs, block volumes, load balancer) – Use or manage Resource Manager stacks (for stack-based listings)

Because IAM policy details can vary and are frequently refined, verify the current required permissions in official Marketplace/IAM documentation: – Marketplace docs: https://docs.oracle.com/en-us/iaas/Content/Marketplace/home.htm
– IAM docs: https://docs.oracle.com/en-us/iaas/Content/Identity/home.htm

Practical guidance: – For labs, a user in an Administrators group (or equivalent broad permissions) is simplest. – For production, create a dedicated group (e.g., Marketplace-Deployer) and scope policies to specific compartments.

Billing requirements

A billing-enabled tenancy is often required to deploy paid listings and sometimes even to launch resources (Compute/storage) even if the listing is free.
For Always Free usage, ensure your account is eligible and you choose Always Free-capable resources (verify Always Free rules).

Tools (optional but recommended)

OCI Console (required for the simplest flow)
OCI CLI (optional, useful for verification and cleanup): https://docs.oracle.com/en-us/iaas/Content/API/Concepts/cliconcepts.htm
SSH client (for VM access)
Terraform knowledge (if using Resource Manager stacks)

Region availability

Marketplace listing availability can vary by region.
Some publishers restrict deployments to certain regions.

Quotas/limits

Your tenancy may have service limits on Compute instances, OCPUs, VNICs, block volumes, etc.
If a deployment fails unexpectedly, check service limits and quotas first.

Prerequisite services (common)

VCN and subnets (or use a wizard to create them)
Compute for VM-based images
Resource Manager for stack deployments

9. Pricing / Cost

Marketplace costs are listing-dependent and the runtime costs depend on what you deploy.

9.1 Pricing dimensions (how charges can happen)

Marketplace listings commonly fall into one of these pricing patterns:

Free listing
– No additional publisher charge via Marketplace
– You still pay for OCI resources you deploy (Compute, storage, load balancer, egress, etc.)
BYOL (Bring Your Own License)
– You provide your own license agreement with the vendor
– You pay OCI infrastructure costs
– Vendor costs are handled outside OCI billing (typically)
Paid listing billed through OCI (metered/subscription)
– Publisher software charges may appear as part of OCI billing (exact billing mechanics vary) – Plus OCI infrastructure costs
SaaS subscription (external)
– Marketplace may facilitate discovery and subscription, but billing and runtime are external
– You might still deploy connectors/agents inside OCI that incur OCI costs

Always read: – Listing pricing tab/section – Terms and conditions – Any additional docs from the publisher

9.2 Free tier / Always Free considerations

Oracle Cloud offers an Always Free tier for certain services in eligible tenancies/regions, but Marketplace listings are not inherently “Always Free”. If you deploy Marketplace software onto Always Free-eligible shapes and minimal storage, your OCI infrastructure might stay within Always Free limits.

Verify Always Free: https://www.oracle.com/cloud/free/

9.3 Cost drivers (direct and indirect)

Direct OCI cost drivers (most common): – Compute instance shape (OCPU count, memory) – Boot and block volume size/performance – Load balancers (if created) – Outbound data transfer (egress) – NAT Gateway usage (if used) – Object Storage usage (if the solution stores backups/artifacts)

Direct Marketplace/publisher cost drivers (listing-dependent): – Hourly metered software fees – Per-instance license fees – Support tier selection

Indirect costs: – Operational overhead (patching, backups, monitoring) – Additional environments (dev/test/prod) – High availability duplicates (2+ instances across fault domains/ADs)

9.5 How to optimize cost

Start with the smallest shape that meets requirements.
Prefer free listings for evaluation.
Stop/terminate instances when not in use.
Use tagging and budgets to track Marketplace-related spend.
Review stack templates to remove unneeded billable components (e.g., load balancer) before production rollout.

9.6 Example low-cost starter estimate (no fabricated numbers)

A typical low-cost evaluation might include: – 1 small VM instance from a free Marketplace image – 1 boot volume (minimal size) – A basic VCN with a public subnet for SSH (or use Bastion) – Minimal outbound data

Exact cost depends on: – Region – Shape and hours run – Storage size and performance – Egress volume – Whether the listing has paid software fees

Use official pricing resources: – OCI pricing overview/price list: https://www.oracle.com/cloud/price-list/ – OCI cost estimator: https://www.oracle.com/cloud/costestimator.html

9.7 Example production cost considerations

In production, costs usually rise due to: – High availability (multiple instances, multiple subnets, potentially multiple regions) – Load balancers and WAF – Larger block volumes and backups – Logging/monitoring retention – Paid software licensing/support

Recommendation: run a cost model that separates: – OCI infrastructure (compute/storage/networking) – Publisher software charges (if billed through OCI) – Operational overhead (people/process/tools)

10. Step-by-Step Hands-On Tutorial

This lab shows a safe, beginner-friendly workflow for Using Marketplace by launching a Marketplace image as a Compute instance, verifying access, and cleaning up.

Because Marketplace listings change over time and vary by region, the tutorial uses a “choose a free image” approach and calls out what to verify.

Objective

Deploy a free Marketplace image into Oracle Cloud (OCI), connect via SSH, verify the instance is running, and then clean up all resources to avoid ongoing costs.

Lab Overview

You will: 1. Create a compartment for the lab (optional but recommended) 2. Create a VCN (network) using a wizard 3. In Marketplace, select a Free image listing and launch a Compute instance 4. Verify the instance is reachable over SSH 5. Validate basic system state 6. Clean up resources

Expected time: 30–60 minutes
Cost: Low, but depends on shape and runtime hours. Stop/terminate afterward.

Step 1: Create a compartment (recommended)

Why: Keeps lab resources isolated for cleanup and access control.

Open the Oracle Cloud Console.
Go to Identity & Security → Compartments.
Click Create Compartment.
Name: cmp-mkt-lab
Description: Marketplace lab resources
Parent compartment: choose appropriately (often the root compartment for labs).
Click Create Compartment.

Expected outcome: A new compartment appears and is in “Active” state.

Verification: – Confirm you can select cmp-mkt-lab from the compartment selector.

Step 2: Create networking (VCN) with a wizard

Why: Most VM images need a VCN + subnet to attach.

Go to Networking → Virtual Cloud Networks.
Select compartment: cmp-mkt-lab.
Click Create VCN.
Choose a wizard option such as VCN with Internet Connectivity (names may vary slightly).
Keep defaults for a lab, and ensure it creates: – VCN – Public subnet – Internet Gateway – Route table rule to the Internet Gateway – Security list allowing required ingress (often SSH)
Click Create.

Expected outcome: A VCN with at least one public subnet.

Verification: – Open the VCN → confirm: – Internet Gateway exists – Public subnet exists – Route rule includes 0.0.0.0/0 to Internet Gateway

Cost note: VCN itself is generally not the cost driver; compute and egress are. Verify current pricing rules in official docs if needed.

Step 3: Choose a free Marketplace image listing

Why: Marketplace images provide prebuilt software environments.

Go to Marketplace in the OCI Console.
Ensure you are in the correct region (top bar).
Search for a listing that meets these lab criteria: – Type: Image (VM image) – Price: Free (or $0 software fee) – Publisher: Prefer Oracle or a well-known vendor – Documentation: Has clear deployment steps

Examples that may exist (availability varies; verify in your region): – Developer-oriented images – Open-source runtime images – Tooling images

Open the listing and read: – Pricing section (ensure software fee is free for the lab) – Support section – Architecture/deployment guidance – Terms (what you’re accepting)

Expected outcome: You have selected a free image listing suitable for launching.

Verification: – Confirm the listing indicates it can be launched as an image on Compute in your region.

Step 4: Launch the Marketplace image as a Compute instance

In the listing page, click Get App / Launch Instance (button text varies).
If prompted, accept terms and conditions.
In the launch workflow: – Compartment: cmp-mkt-lab – Instance name: vm-mkt-lab-01 – Availability domain/fault domain: leave default – Image: should be the Marketplace image you selected – Shape: choose a small shape appropriate for labs (and Always Free-eligible where possible) – Networking:
- VCN: the lab VCN from Step 2
- Subnet: public subnet
- Assign a public IPv4 address: Yes (for simplest SSH; in production prefer Bastion/private)
- SSH keys:
- Generate a new key pair (download private key) or paste your public key
Click Create (or Launch).

Expected outcome: Instance provisioning starts and eventually reaches Running state with a public IP.

Verification: – Navigate to the instance details page: – Lifecycle state: Running – Public IPv4 address: present – VNIC attached

Common issue: If the shape selection fails due to limits, check service limits/quotas for Compute.

Step 5: Configure SSH access from your workstation

On your machine, ensure the private key has correct permissions.

chmod 600 ~/Downloads/ssh-key-2026-*.key

Identify: – PUBLIC_IP from the instance page – SSH_USER from listing documentation (this varies by image)

Common usernames for OCI images include opc (but do not assume—verify the listing details).

Connect:

ssh -i ~/Downloads/ssh-key-2026-*.key <SSH_USER>@<PUBLIC_IP>

Expected outcome: You get a shell prompt on the VM.

Verification commands (run on the VM):

uname -a
cat /etc/os-release

If the listing is supposed to have preinstalled software, verify per its docs (examples):

# Examples only—use commands relevant to your chosen listing
python3 --version
docker --version
java -version

Step 6: (Optional) Verify network exposure is minimal

For a lab you might have opened SSH broadly. Confirm your security list/NSG is not more permissive than needed.

Go to the instance → VNIC → Subnet → Security List (or NSG if used).
Confirm inbound rules: – SSH (TCP/22) from your IP is preferred – Avoid 0.0.0.0/0 in production

Expected outcome: Inbound access is constrained.

Verification: – SSH remains accessible from your machine after tightening rules.

Validation

You have successfully used Oracle Cloud Marketplace to: – Select a listing – Accept terms – Launch a Marketplace image as a Compute instance – Connect to it and validate system status

Checklist: – Instance is Running – Public IP assigned (lab) – SSH works with your key – OS/software matches the listing documentation

Troubleshooting

Issue: Instance fails to launch – Check service limits (Compute OCPUs, instances). – Try a smaller shape. – Ensure your chosen listing supports your region and shape type.

Issue: SSH connection times out – Confirm instance has a public IP. – Confirm subnet route table has 0.0.0.0/0 to an Internet Gateway. – Confirm security list/NSG allows inbound TCP/22 from your source IP. – Confirm local firewall/corporate network allows outbound SSH.

Issue: SSH “Permission denied (publickey)” – Verify you used the correct private key. – Verify the correct username from listing documentation. – Confirm the key you uploaded matches the private key you’re using.

Issue: Unexpected charges – Verify whether the listing has a paid software component. – Ensure you terminate the instance and delete any load balancers or extra volumes created by templates. – Use cost analysis (OCI billing tools) and tags to identify resources.

Cleanup

To avoid ongoing charges, clean up resources created by the lab.

Terminate the Compute instance – Compute → Instances → vm-mkt-lab-01 → Terminate – Choose to delete attached boot volume (for full cleanup) unless you intentionally want to keep it
Delete the VCN – Networking → VCNs → select your lab VCN → Terminate – If deletion fails, remove dependent resources first (instances, gateways, route rules, subnets)
Delete the compartment (optional; only if it contains no resources) – Identity → Compartments → cmp-mkt-lab → Delete
Review for leftovers – Check for block volumes, public IPs, load balancers, NAT gateways, etc.

11. Best Practices

Architecture best practices

Prefer stack-based (IaC) deployments for repeatability and auditability.
Use a landing zone approach:
Separate compartments for network, shared services, and applications
Dedicated subnets for management vs application traffic
For production, design for:
Multi-fault-domain deployments (where applicable)
Load balancers and health checks
Backup and restore workflows

IAM/security best practices

Enforce least privilege:
Separate “Marketplace subscription” rights from “resource creation” rights if your process requires approvals.
Use compartments to constrain blast radius.
Require MFA and federated identity where possible.
Restrict who can accept Marketplace terms (procurement/legal alignment).

Cost best practices

Tag every Marketplace-deployed resource with:
CostCenter, Environment, Application, Owner
Prefer minimal shapes in dev/test and schedule shutdowns.
Review stack templates to understand what billable resources will be created before deploying.

Performance best practices

Validate sizing guidance from the listing and benchmark with your workload.
Ensure network design matches throughput requirements (LB shape, subnet design, NSG rules).
Avoid over-provisioning early; scale based on metrics.

Reliability best practices

Use multiple instances and health checks for critical components.
Store configuration in code (Git), not only in manual console settings.
Plan for patch windows and upgrades (publisher images do not automatically keep you safe).

Operations best practices

Integrate with OCI Monitoring, Logging, and Alerts from day one.
Use OS Management (where appropriate) or your standard patch toolchain (verify current OCI OS management options).
Document:
What was deployed (listing version, parameters)
How it’s supported (vendor vs internal)
How to restore/recreate (runbooks)

Governance/tagging/naming best practices

Naming conventions:
env-app-component-region-## (example: prod-payments-fw-phx-01)
Use tag defaults at compartment level where possible.
Treat Marketplace deployments as code:
Store inputs/parameters
Store version references
Require peer review for production

12. Security Considerations

Identity and access model

Marketplace actions are governed by OCI IAM.
Control who can:
Browse listings (read-only)
Accept terms/subscribe
Deploy resources (create/modify Compute/Network/etc.)
Use compartment scoping to prevent accidental production deployments.

Encryption

OCI resources such as block volumes support encryption by default (verify current defaults and options in official docs).
For application-level secrets:
Use OCI Vault for keys and secrets
Avoid embedding secrets in cloud-init or Terraform variables in plain text

Network exposure

Avoid public IPs in production unless required.
Use OCI Bastion for SSH/RDP access patterns.
Place appliances in dedicated subnets and restrict east-west movement with NSGs and route controls.
Consider WAF and Load Balancer for public web exposure.

Secrets handling

Do not store passwords/API keys in:
User-data scripts
Git repositories
Instance metadata in plaintext
Use Vault and instance principals (where supported) for OCI API access patterns.

Audit/logging

Ensure OCI Audit is enabled and monitored (Audit is generally enabled by default; verify retention and access).
Forward critical logs to a central logging system; restrict who can disable logging.

Compliance considerations

Validate:
Publisher claims (certifications, compliance) directly in official listing docs and vendor sites.
Data residency and region requirements.
Keep an inventory of:
Marketplace listing name/version
Deployed software versions
Patch status and exceptions

Common security mistakes

Deploying from unknown publishers without validation
Leaving SSH open to the internet (0.0.0.0/0)
Forgetting to patch images and dependencies
Accepting terms/licensing without procurement review
Not scanning instances for vulnerabilities post-deploy

Secure deployment recommendations

Use private subnets + Bastion where possible.
Apply NSGs with least-privilege ports.
Enable monitoring and alerting immediately.
For stacks, review Terraform code before applying:
Look for overly permissive security rules
Validate IAM policies created by templates
Confirm no unexpected public endpoints

13. Limitations and Gotchas

Listing availability varies by region. A solution you see in one region may not be deployable in another.
“Free listing” does not mean “free deployment.” Compute, storage, load balancer, and egress can still cost money.
Publisher support boundaries: Oracle supports OCI infrastructure; publishers support their software—unless explicitly stated otherwise.
Image drift: Marketplace images may become outdated if you don’t patch after deployment.
Stacks can create many resources quickly: including expensive components. Always review the template and planned resources before deploying.
IAM complexity: Marketplace subscriptions + resource creation may require multiple policy permissions.
Network defaults may be insecure: some templates open broad ingress for convenience; tighten for production.
Upgrades are on you: launching an image is not the same as managed service upgrades.
Compatibility constraints: certain images may require specific shapes, CPU architectures, or OS versions.
Termination doesn’t always delete everything: stacks may leave behind volumes, public IPs, or buckets; validate cleanup.

14. Comparison with Alternatives

How Using Marketplace compares

Using Marketplace is best viewed as “solution acquisition + deployment integration”. Alternatives vary depending on what you’re trying to achieve.

Option	Best For	Strengths	Weaknesses	When to Choose
Oracle Cloud Using Marketplace (OCI Marketplace)	Deploying partner/Oracle solutions into OCI with terms + optional integrated billing	Integrated with OCI IAM/compartments; images and stacks; supports multiple pricing models	Listing availability varies; quality varies by publisher; you still operate the runtime	When you need vendor solutions deployed into OCI quickly with governance
OCI Compute custom images / golden images	Standard internal images with consistent hardening	Full control; consistent baseline; integrates with your CI image pipeline	Requires you to build/maintain images and software	When you have strict security baselines or need internal standardization
OCI Resource Manager (direct Terraform, not via Marketplace)	Infrastructure as code for OCI without Marketplace catalog	Full flexibility; version-controlled modules	No catalog discovery; more work to build templates	When you already have Terraform modules and want full control
AWS Marketplace	Similar marketplace flow on AWS	Broad ecosystem; tight integration with AWS services	Different IAM/networking model; not OCI	Choose if your workloads run primarily on AWS
Azure Marketplace	Similar on Microsoft Azure	Strong enterprise procurement integrations	Not OCI; different deployment constructs	Choose if your workloads run primarily on Azure
Google Cloud Marketplace	Similar on Google Cloud	Integrated with GCP deployment patterns	Not OCI; different constructs	Choose if your workloads run primarily on GCP
Self-managed installs from vendor repos	Maximum control, minimal marketplace coupling	No marketplace constraints; fully customizable	Higher setup time; more integration effort; licensing procurement is manual	When Marketplace doesn’t offer what you need or you require custom builds

15. Real-World Example

Enterprise example: Shared security services rollout

Problem: A financial enterprise needs to standardize a network security appliance across multiple application teams. Teams currently deploy ad-hoc solutions with inconsistent configurations.
Proposed architecture:
A dedicated Shared Services compartment
Hub VCN with dedicated subnets for security appliances
Marketplace image deployment of the vendor appliance (two instances for HA where supported)
Spoke VCNs for application teams with controlled routing through the hub
Centralized logging to OCI Logging (and/or external SIEM)
Why Using Marketplace was chosen:
Official vendor-provided image and documented OCI deployment pattern
Clear support boundaries and licensing approach
Repeatable deployment with consistent versions
Expected outcomes:
Faster onboarding for new application VCNs
Improved audit posture via standard deployment and OCI Audit logs
Reduced risk from inconsistent firewall deployments

Startup/small-team example: Quick POC environment for a customer demo

Problem: A startup needs to demo a secure web app architecture to a customer within a week, without spending days on manual setup.
Proposed architecture:
One compartment for demo
VCN + public subnet (lab) or private subnet + Bastion (more secure)
Marketplace image for a preconfigured reverse proxy or app runtime (listing-dependent)
Basic alarms and logging
Why Using Marketplace was chosen:
Speed: deploy a working environment in hours
Lower complexity than assembling components manually
Expected outcomes:
Repeatable demo environments
Easy teardown to control costs
Faster iteration during customer feedback cycles

16. FAQ

1) Is “Using Marketplace” a separate billable Oracle Cloud service?
Not typically. Marketplace is a catalog and deployment integration. Costs come from (a) OCI resources you deploy and (b) listing-specific software charges if the publisher bills through OCI. Always check the listing pricing and OCI billing.

2) Do I need a paid account to use Marketplace?
You need a valid tenancy and the ability to provision underlying resources. Even for free listings, resource provisioning may require a billing-enabled account. Verify current account requirements and Always Free eligibility.

3) Can I deploy Marketplace images into private subnets?
Yes, in many cases. You must ensure the instance can reach required update repositories or license endpoints (via NAT Gateway, Service Gateway, or private connectivity), and you must provide a secure access pattern (Bastion, VPN).

4) How do I know if a listing is safe?
Check publisher identity, documentation quality, update cadence, support model, and community/vendor reputation. For production, perform security reviews: scan the instance, review open ports, and validate configuration.

5) Who supports the software: Oracle or the publisher?
Usually the publisher supports their software; Oracle supports OCI infrastructure. Some listings might have different arrangements—verify the listing’s support section.

6) Can Marketplace stacks create IAM policies automatically?
Some stacks may create IAM resources if designed to. Treat this as high risk: review Terraform before applying and use least privilege.

7) What happens if I terminate a VM launched from a Marketplace image?
The VM stops existing, but attached resources (boot volume, block volumes, public IPs) may remain depending on your termination options and template behavior.

8) Can I automate Marketplace deployments with CI/CD?
Often yes, especially with stack-based deployments (Terraform/Resource Manager). The exact automation path depends on the listing and OCI APIs. Verify current supported automation methods in OCI docs.

9) Are Marketplace images updated automatically after I launch them?
No. Once launched, it’s your responsibility to patch and maintain the instance unless you use a managed service or automation tooling.

10) Can I restrict which listings my organization can deploy?
You can restrict who can deploy by IAM and compartments, and you can build internal controls (approvals, curated processes). The exact mechanisms for “allowlisting listings” should be verified in official docs and your governance tooling.

11) Why can’t I find a listing that someone else sees?
Common reasons: region differences, tenancy restrictions, listing retired/updated, or publisher availability constraints.

12) Do Marketplace deployments work with ARM-based shapes and different CPU architectures?
Some images support specific architectures only. Check listing requirements and supported shapes.

13) How do I estimate cost before deploying a listing?
Identify resources the deployment will create (compute, storage, LB, NAT, etc.) and use the OCI cost estimator. For paid listings, include publisher fees described in the listing.

14) Can I use my own SSH keys and hardening standards with Marketplace images?
Yes. You generally provide your SSH keys during instance launch and can apply your standard hardening after deployment (CIS baselines, agent installs, etc.).

15) What’s the best practice for production: image or stack?
For production, stacks (IaC) often provide better repeatability and auditability. Images can still be appropriate, but you should wrap them in IaC and operational controls.

16) Can I migrate a Marketplace deployment between regions?
Not directly. You typically redeploy in the target region and migrate data/configuration using standard methods. Validate licensing terms for multi-region usage.

17) What should I document for compliance?
At minimum: listing name/version, publisher, pricing model, acceptance of terms, deployment parameters, network exposure, patching policy, support contacts, and audit logs retention.

17. Top Online Resources to Learn Using Marketplace

Resource Type	Name	Why It Is Useful
Official documentation	OCI Marketplace docs	Canonical reference for Marketplace concepts and workflows: https://docs.oracle.com/en-us/iaas/Content/Marketplace/home.htm
Official documentation	OCI IAM docs	Required to design permissions safely: https://docs.oracle.com/en-us/iaas/Content/Identity/home.htm
Official documentation	OCI Resource Manager docs	Important for stack-based Marketplace deployments: https://docs.oracle.com/en-us/iaas/Content/ResourceManager/home.htm
Official pricing	Oracle Cloud price list	Understand baseline OCI service pricing: https://www.oracle.com/cloud/price-list/
Official pricing tool	OCI Cost Estimator	Model costs before deployment: https://www.oracle.com/cloud/costestimator.html
Official Free Tier	Oracle Cloud Free Tier	Always Free eligibility and limits: https://www.oracle.com/cloud/free/
Architecture center	Oracle Architecture Center / Solutions	Reference architectures and patterns: https://docs.oracle.com/en/solutions/
Official tutorials	Oracle Cloud “Learn”	Guided labs and tutorials (search for Marketplace/Resource Manager): https://docs.oracle.com/en/learn/
Official videos	Oracle Cloud YouTube channel	Product walkthroughs and demos; search Marketplace: https://www.youtube.com/@OracleCloudInfrastructure
Samples (trusted)	Oracle GitHub org	IaC samples and reference code (verify Marketplace relevance per repo): https://github.com/oracle

18. Training and Certification Providers

The following training providers may offer Oracle Cloud, DevOps, and cloud marketplace-related learning. Verify current course availability and delivery modes on each website.

Institute	Suitable Audience	Likely Learning Focus	Mode	Website
DevOpsSchool.com	DevOps engineers, SREs, cloud engineers	DevOps practices, cloud automation, IaC fundamentals	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate DevOps learners	SCM, CI/CD, DevOps tooling basics	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud operations teams	Cloud ops, monitoring, reliability practices	Check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, platform engineers	SRE principles, incident response, reliability engineering	Check website	https://www.sreschool.com/
AiOpsSchool.com	Ops teams exploring AIOps	AIOps concepts, automation, operational analytics	Check website	https://www.aiopsschool.com/

19. Top Trainers

These sites may provide trainer profiles, training services, or learning resources. Verify background, curriculum, and Oracle Cloud coverage directly.

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	DevOps/cloud training content	Students, engineers seeking guided learning	https://www.rajeshkumar.xyz/
devopstrainer.in	DevOps coaching/training	DevOps engineers, CI/CD practitioners	https://www.devopstrainer.in/
devopsfreelancer.com	Freelance DevOps support/training	Small teams needing hands-on help	https://www.devopsfreelancer.com/
devopssupport.in	Operational support and training resources	Ops teams, DevOps teams	https://www.devopssupport.in/

20. Top Consulting Companies

These organizations may offer consulting for DevOps, cloud adoption, automation, and operations. Validate OCI Marketplace-specific experience during vendor selection.

Company	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting	Architecture, automation, deployments	Marketplace-based deployment standardization; IaC rollout; ops runbooks	https://www.cotocus.com/
DevOpsSchool.com	DevOps consulting & training	DevOps transformation, CI/CD, tooling	Building deployment pipelines for Marketplace stacks; governance and tagging strategy	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting	DevOps implementation and support	Production hardening of Marketplace images; monitoring/logging integration	https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Using Marketplace

OCI fundamentals:
Tenancy, compartments, regions
VCN basics (subnets, routing, gateways, NSGs)
Compute basics (instances, shapes, boot volumes)
IAM:
Users, groups, policies, least privilege
Basic Linux administration:
SSH, firewall concepts, package management
Cost basics:
How OCI charges for compute/storage/egress
Tagging and budgeting concepts

What to learn after Using Marketplace

Infrastructure as Code:
Terraform fundamentals
OCI Resource Manager workflows
Production networking patterns:
Hub-and-spoke, private subnets, bastion, load balancers
Observability:
OCI Monitoring, Logging, alarms, dashboards
Security hardening:
Vulnerability scanning, patching, secrets management (Vault)
Governance:
Policy-as-code, change management, release pipelines

Job roles that use it

Cloud engineer / cloud administrator
Solutions architect
DevOps engineer / platform engineer
SRE
Security engineer (especially for appliance deployments)
FinOps analyst (tracking and optimizing Marketplace-related spend)

Certification path (if available)

Oracle Cloud certifications change over time. Use Oracle University for the latest certification tracks and exam codes (verify current paths): https://education.oracle.com/

Project ideas for practice

Build a “curated Marketplace deployment” pipeline:
Approved listing → IaC stack → private subnet deployment → monitoring + alerts
Create a cost dashboard for Marketplace deployments using tags.
Design a multi-environment pattern (dev/stage/prod) with compartment separation and policy boundaries.
Build a hardened VM baseline process for Marketplace images (post-launch hardening scripts + CIS checks).

22. Glossary

Oracle Cloud (OCI): Oracle Cloud Infrastructure, the IaaS platform where Marketplace deployments run.
Marketplace: Oracle Cloud Marketplace catalog of partner/Oracle solutions.
Using Marketplace: The workflow of discovering, subscribing, and deploying Marketplace listings into your OCI tenancy.
Listing: A catalog entry in Marketplace describing a solution, its artifacts, pricing, and support.
Publisher: The vendor or organization that provides the listing.
Image (Marketplace image): A VM image used to launch a Compute instance with preinstalled software.
Stack: A deployable IaC template (commonly Terraform) that provisions multiple OCI resources.
OCI Resource Manager: OCI service that runs Terraform to provision resources.
Tenancy: Your top-level OCI account boundary.
Compartment: A logical isolation boundary inside a tenancy for organizing and controlling access to resources.
IAM Policy: Rules that define who can do what to which resources in OCI.
BYOL: Bring Your Own License; you supply an existing software license.
Metered billing: Usage-based billing, often hourly or by consumption units, depending on the listing.
VCN: Virtual Cloud Network, OCI’s virtual networking construct.
NSG: Network Security Group, used to apply security rules to VNICs.
Internet Gateway / NAT Gateway: VCN components providing internet connectivity (inbound/outbound patterns differ).
OCI Audit: Service that records API calls and actions for governance and security investigations.
OCPU: Oracle CPU unit used in OCI compute sizing (pricing and meaning can vary by shape type; verify current definitions in OCI docs).

23. Summary

Using Marketplace in Oracle Cloud is the disciplined way to find, evaluate, subscribe to, and deploy Marketplace solutions into your OCI tenancy. It matters because it shortens delivery timelines, supports repeatable deployments (especially with stacks), and provides a governed path to adopt vendor software while staying inside OCI’s IAM and compartment model.

Cost-wise, Marketplace is not “automatically free”—you pay for the OCI resources you deploy, and some listings add publisher software charges depending on licensing and billing model. Security-wise, treat Marketplace artifacts like any supply-chain input: validate publishers, review templates, restrict network exposure, and establish patching and monitoring from day one.

Use Using Marketplace when you need fast, standardized deployments of vendor solutions with clear terms and operational integration into OCI. Next, deepen your skills with OCI Resource Manager (Terraform) and production governance (IAM, tagging, monitoring, and security hardening) so Marketplace deployments remain safe, repeatable, and cost-controlled.

rajeshkumar

Category