summaryrefslogtreecommitdiff
path: root/docs/tutorials/podman-derivative-api.md
diff options
context:
space:
mode:
Diffstat (limited to 'docs/tutorials/podman-derivative-api.md')
-rw-r--r--docs/tutorials/podman-derivative-api.md4
1 files changed, 3 insertions, 1 deletions
diff --git a/docs/tutorials/podman-derivative-api.md b/docs/tutorials/podman-derivative-api.md
index 0342bb740..065b0c4a9 100644
--- a/docs/tutorials/podman-derivative-api.md
+++ b/docs/tutorials/podman-derivative-api.md
@@ -1,3 +1,5 @@
+![PODMAN logo](../../logo/podman-logo-source.svg)
+
# How to use libpod for custom/derivative projects
libpod today is a Golang library and a CLI. The choice of interface you make has advantages and disadvantages.
@@ -41,4 +43,4 @@ Making the choice
A good question to ask first is: Do you want users to be able to use `podman` to manipulate the containers created by your project?
If so, that makes it more likely that you want to run `podman` as a subprocess. If you want a separate image store and a fundamentally
different experience; if what you're doing with containers is quite different from those created by the `podman` CLI,
-that may drive you towards vendoring. \ No newline at end of file
+that may drive you towards vendoring.